check the DB table fields_meta_data and the directory custom/Extension/modules//Ext/Vardefs/ If there are files in the latter that resemble: sugarfield__c.php, that are not represented in the former, then removing them should clear up the issue. (from pmcqueen)
check the DB table fields_meta_data and the directory custom/Extension/modules//Ext/Vardefs/ If there are files in the latter that resemble: sugarfield__c.php, that are not represented in the former, then removing them should clear up the issue. (from pmcqueen)
(Quote from pmcqueen)check the DB table fields_meta_data and the directory custom/Extension/modules//Ext/Vardefs/ If there are files in the latter that resemble: sugarfield__c.php, that are not represented in the former, then removing them should clear up the issue.(End Quote) Thank you... it solved (from SpockPT)
Tried to solve the same situation, find the sugarfieldxxxx.php file, and deleted. Quick repair and rebuild, and nothing happens: null is still there. Additionally, when trying to create a record, I get a database error in sugarcrm.log. This is the offending portion of the sql: SET name = 'Opportunity name' , date_modified='.........................................probability=20,[B]=NULL[/B] There is a field name missing, but I noted, and don't know if this is relevant, that SET is made over not custom fields (there are no '_c' fields in the query). Additionally supposing (not custom) vardefs.php is modifed by hand, is expected that when a repair and rebuild is executed, sugar realizes the situation and create the missing fields in the database... and in this case, fields_meta_data table does not make the difference. Please tell me if I am wrong.. There must be another file in some place causing this.. (from hdanielb)
@hdanielb, I am experiencing the same issue - apparently not caused by a custom field (UPDATE accounts SET ...,campaign_id='',=NULL) and unable to find the file where that rogue NULL field is coming from. Did you manage to find and resolve the issue? (from almcnicoll)
As a follow-up - here's how I got around the issue, then fixed it. I ran a backtrace (PHP: debug_print_backtrace) and worked my way back through the stack to the UpdateSQL call on the DBManager class (/include/database/DBManager.php). Around line 1950 - just before the branching if that adds items to the columns array ($columns[] = ...) I added the following: [code] if (trim($fieldDef['name']) == '') { // Null fields in Studio - shouldn't happen, but they do error_log('Skipping field as it has no name. Field def follows:\n'.print_r($fieldDef,true)); continue; } [/code] This gave me an output to the PHP error log (yes, I could have used the sugar log, but the error log is less cluttered on my system!) of the field definition, which contained a lot of information about the field, but no name. I then recognised it as a custom field that for some reason hadn't been added properly. Thankfully, I have since discovered I can do without it, and have commented out the /custom/ references to it. Hope this saves someone the hour it took me..! (from almcnicoll)
Has anyone found the reason why the extra =Null,=NULL,=NULL are included? And how to fix this?
Here is my guess...I tried to create three new fields, but it kept giving a SQL error. Then this error started to appear when I tried to save/update my data. Later, I looked at this a little more and noticed that the original SQL error was because SugarCRM was attempted to modify an existing database column's datatype from date to datetime. There was one record in which the year was 1512 and that year is not allowed as a datetime. Because of all this, it seems that Sugar started to create a new field but was not successful. But now I don't know how to remove these "unsuccessful" columns.
