After adding a new form field to the default form the 'ticket__cdata' table disappears from my database.  I've added various types such as 'short answer', 'section break' etc. and it's the same result each time.  I'm not sure why this is happening but it's easy to reproduce within my installation just by adding a new form field.  I haven't dug into every table but what's odd is that though this mysql table is missing, tickets are displaying these form fields (which is expected) but also saving whatever info I edit into the ticket.  My understanding was that all these form fields (when not taken from a custom list) are stored in the ticket__cdata table so it's odd how data is being stored when the table does not exist.

My understanding is that the system nukes and recreates the __cdata table every so often. Several of the past upgrade scripts nuke the table (1.8.1, 1.9.4 to name two off the top if my head).  form data is actually stored in ost_form_field and ost_form_entry_values.Are you running cron.php?

Yes, cron.php is running, verified by 'Auto Cron' showing in system logs.  I reverse engineered the tables to see where all this data was being stored which brought me to `ost_form_field` and `ost_form_entry_values`.  Until I do a proper update (I'm on v1.9.5.1 and assuming an updated version won't have this issue) I manually create data in the 2 tables you mentioned but also a new column in `ticket__cdata` with the field variable.  This seems to work as I'm able to update the fields in the ticket editor, verify sql is being saved and the `ticket__cdata` does not get deleted.

Write a Reply...