New Issue - CRM not saving records

jwaugh · 23 August 2017 13:34

New issue started Friday. When a user enters a new contact or lead either;

a. it takes over two minutes to save
b. nothing saves and Im taken to a white, http screen with error 500, This Page isnt Working

Steps taken to resolve unsuccessfully;

a. rebuild repair tool in crm
b. updated from version 7.8.3 to version 7.8.5

Neither steps fixed the problem.

Is there a file somewhere limiting entries or would this be more of a possible hard drive issue? Any pointers in the right direction would be greatly appreciated.
Thank you in advance.

pgr · 23 August 2017 17:43

You should start by checking your logs for errors at the time the application malfunctions.

Do you have an enormous number of records?

jwaugh · 24 August 2017 13:27

There are numerous logs in suitecrm.log file. After adding an email and executing a save I see the following in that log:

Thu Aug 24 09:04:33 2017 [4926][1][FATAL] Query Failed: DESCRIBE versions: MySQL error 1146: Table ‘CRM.versions’ doesn’t exist
Thu Aug 24 09:04:33 2017 [4926][1][FATAL] Query Failed: SHOW INDEX FROM versions: MySQL error 1146: Table ‘CRM.versions’ doesn’t exist
Thu Aug 24 09:04:33 2017 [4926][1][FATAL] Query Failed: select * from versions: MySQL error 1146: Table ‘CRM.versions’ doesn’t exist

Database size is certainly not an issue. Results of query in phpMyAdmin:

SELECT CONCAT(table_schema, ‘.’, table_name),
CONCAT(ROUND(table_rows / 1000000, 2), ‘M’) rows,
CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), ‘G’) DATA,
CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), ‘G’) idx,
CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), ‘G’) total_size,
ROUND(index_length / data_length, 2) idxfrac
FROM information_schema.TABLES
ORDER BY data_length + index_length DESC
LIMIT 10;

CONCAT(table_schema, ‘.’, table_name) rows DATA idx total_size idxfrac
CRM.aod_indexevent 0.01M 0.00G 0.00G 0.00G 0.92
CRM.sugarfeed 0.00M 0.00G 0.00G 0.00G 0.34
asterisk.module_xml 0.00M 0.00G 0.00G 0.00G 0.00
asterisk.kvstore 0.00M 0.00G 0.00G 0.00G 0.02
CRM.leads 0.00M 0.00G 0.00G 0.00G 1.59
CRM.email_addr_bean_rel 0.00M 0.00G 0.00G 0.00G 1.25
CRM.accounts_contacts 0.00M 0.00G 0.00G 0.00G 2.24
CRM.tracker 0.00M 0.00G 0.00G 0.00G 1.21
CRM.accounts 0.00M 0.00G 0.00G 0.00G 1.19
CRM.contacts 0.00M 0.00G 0.00G 0.00G 1.87

Continuing to have the issue. Email addresses will not save. New contact will save but only after refresh.

pgr · 24 August 2017 13:42

I’ve seen those errors before. That table “versions” was deprecated a few versions ago. My 7.9.4 system doesn’t have it. But it seems some code is left-ove that is looking for it.

However, I’m pretty sure that error doesn’t occur when going through screens, but only in upgrades, am I right? Please double-check the timestamps on those errors, and try to infer what you were doing when they occurred.

It would be nice to get us an error message exactly when the problem occurs. Maybe when you get a blank screen, you can find an error message in php_errors.log.

elentz · 24 August 2017 14:50

I am working with Jason on this. There are no errors in the php_errors log file (we had to enable it) We are getting an error in the HTTPD log

[Thu Aug 24 10:42:07 2017] [error] [client 192.168.0.68] PHP Strict Standards: Declaration of MyAccountsDashlet::process() should be compatible with DashletGeneric::process($lvsParams = Array, $id = NULL) in /var/www/html/CRM/modules/Accounts/Dashlets/MyAccountsDashlet/MyAccountsDashlet.php on line 48, referer: http://192.168.0.251/CRM/index.php

It appears to manifest when a record is either being edited or created

pgr · 24 August 2017 15:16

That error can be fixed. In fact, I thought it was already fixed in 7.8.5.

You just go into

modules/Accounts/Dashlets/MyAccountsDashlet/MyAccountsDashlet.php

and change the declaration of process (around line 86) to look like this:

function process($lvsParams = array(), $id = NULL) {

But that error should be showing when the Home screen displays, not when other actions like Saving are made… so I’m not sure it’s related.

jwaugh · 24 August 2017 19:16

What is odd is that the email field will not save regardless of whether the page times out with an error 500 white page. Other fields will still save.

pgr · 25 August 2017 16:40

I don’t know if this blog post might help you check your database for anything weird in the area of email addresses:

https://pgorod.github.io/How-Emails-Stored/

You can try some queries from phpMyAdmin, or run database repairs on those tables and any related indexes.

If you get long delays when working directly on the database, then you know it’s not a SuiteCRM app problem. Try an INSERT or two. If you bring the suitecrm log level up to DEBUG you can see the exact queries SuiteCRM is trying, and you can try them directly in MySQL.

elentz · 1 September 2017 12:02

Still stuggling with this issue. Some more info from the users… Here is their issues:

When editing an account, the system will not save the e-mail address, when creating a new lead, good luck finding it later – it won’t come up on any searches. Takes forever to save an edited task, notes take a long time to save too. Opening notes takes a bit long as well

Anything here give an idea what might be going on?

pgr · 1 September 2017 12:12

Did you try any of my suggestions in the last post? Tell me if you run into any difficulty.

elentz · 1 September 2017 13:01

I went to that blog and ran the query and got back emails for our users. I ran repair table on the tables listed there, that ran pretty quick. I do not know where to elevate the log to debug, can you tell me that? Also, where is that log file kept? Do you know if the system validates email addresses when entering new or updating a record?

Thanks

pgr · 1 September 2017 13:39

You can change the logger settings in Admin / System settings, at the bottom of the screen. You can set the filename and the debug level.

Normally it’s sugarcrm.log (for people upgrading from Sugar) or suitecrm.log, both at the root of your installation.

I don’t really know how the code works, but the extra logging might help us get nearer to the location of the problem in the code.

But I find your big delays very suspicious. They make me think of corrupted data or files, not of coding bugs. But let’s see what the logs tell us.

elentz · 1 September 2017 18:42

One of my users refreshed his page and got this result:

Unknown Error (8192): Non-static method SugarWidgetReportField::_get_column_select() should not be called statically, assuming $this from incompatible context occurred in /var/www/html/CRM/include/generic/SugarWidgets/SugarWidgetFieldname.php on line 248 [2017-09-01 13:24:43] display_stack_trace caller, file: /var/www/html/CRM/include/utils.php line#: 3413
/var/www/html/CRM/include/generic/SugarWidgets/SugarWidgetFieldname.phpL:248
/var/www/html/CRM/include/Dashlets/DashletGeneric.phpL:343
/var/www/html/CRM/include/Dashlets/DashletGeneric.phpL:391
/var/www/html/CRM/modules/Meetings/Dashlets/MyMeetingsDashlet/MyMeetingsDashlet.phpL:109
/var/www/html/CRM/modules/Home/index.phpL:236
/var/www/html/CRM/modules/Home/views/view.list.phpL:52
/var/www/html/CRM/include/MVC/View/SugarView.phpL:169
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:363
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:310
/var/www/html/CRM/include/MVC/SugarApplication.phpL:105
/var/www/html/CRM/index.phpL:52

This was right below it

Unknown Error (8192): Non-static method SugarWidgetReportField::_get_column_select() should not be called statically, assuming $this from incompatible context occurred in /var/www/html/CRM/include/generic/SugarWidgets/SugarWidgetFieldname.php on line 248 [2017-09-01 13:24:48] display_stack_trace caller, file: /var/www/html/CRM/include/utils.php line#: 3413
/var/www/html/CRM/include/generic/SugarWidgets/SugarWidgetFieldname.phpL:248
/var/www/html/CRM/include/Dashlets/DashletGeneric.phpL:343
/var/www/html/CRM/include/Dashlets/DashletGeneric.phpL:391
/var/www/html/CRM/modules/Meetings/Dashlets/MyMeetingsDashlet/MyMeetingsDashlet.phpL:109
/var/www/html/CRM/include/MySugar/retrieve_dash_page.phpL:267
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:864
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:394
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:307
/var/www/html/CRM/include/MVC/SugarApplication.phpL:105
/var/www/html/CRM/index.phpL:52
,
I went into the log and there were no errors Nothing called an error for that time frame When I search by time 13:24 and set reg exp on I get ALOT of this:

L:
/var/www/html/CRM/modules/Configurator/LogView.phpL:160
/var/www/html/CRM/include/MVC/View/SugarView.phpL:761
/var/www/html/CRM/include/MVC/View/views/view.classic.phpL:74
/var/www/html/CRM/include/MVC/View/SugarView.phpL:169
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:363
/var/www/html/CRM/include/MVC/Controller/SugarController.phpL:310
/var/www/html/CRM/include/MVC/SugarApplication.phpL:105
/var/www/html/CRM/index.phpL:52
Warning: preg_match(): Delimiter must not be alphanumeric or backslash occurred in /var/www/html/CRM/modules/Configurator/LogView.php on line 160 [2017-09-01 14:39:16]

Does this tell you anything? The whole log is filled with thie entry over and over again

pgr · 1 September 2017 21:24

What is your version of PHP?

I assume SuiteCRM version is 7.8.5 as stated above, can you confirm?

elentz · 1 September 2017 23:00

Yes SuiteCRM is at 7.8.5 and PHP is at 5.6.30

pgr · 2 September 2017 10:50

The preg_match error is actually an error in the code that is grepping your log. It seems you entered a reg exp filter that doesn’t play well. Exactly what was it, just “13:24” or did you add any other characters or delimiters?

Anyway, that doesn’t really matter to your most important problem.

I think it would be better if you started looking at the logs from Linux, not from the Web UI. And don’t just grep them, give us a full DEBUG log (with hundreds of lines, if necessary - just put it inside the forum’s code tags) of the time before pressing the button for the long delayed queries, up to the time when it ends.

By examining the time stamps of the messages we can probably see between which two points it is hanging. Even if those messages are not error messages.

elentz · 2 September 2017 12:05

You are right I just put in 13:24 for the search. I will see if I can replicate the error and get the log entries online. Thank you so much for your help so far!

pgr · 3 September 2017 16:44

Hi

I asked for 3 minutes’ worth of suitecrm.log, you posted 18 hours of syslog… your post was so long that I couldn’t get into this page to answer you, it would hang…

I had to ask Dillon Brown who is an admin to delete that post so we could continue on this thread. I suspect this involves some kind of bug in the forum software, it really shouldn’t hang eternally just because of a long post.

Anyway, going forward:

Please set your log to DEBUG level (in Admin / System Settings), and give me the lines from suitecrm.log around the time when you press the button to see the operation that gives that long delay. I want to see the log from just before it begins, to after it ends (and nothing else!).

Thanks and sorry for this confusion.

P.S. - if you get too much text perhaps you can paste it in pastebin.com and just give us a link here.

elentz · 3 September 2017 19:10

Oops sorry about that! I saw that the system appeared to reset and I wanted to make sure you saw that. So, I have the log set for debug, now if I can just get it to fail. I will do my best.
Thanks

pgr · 3 September 2017 19:24

I like this quote…

About your syslog: I still have it in the email that the forums sent when you posted. It has a LOT of Cups errors, that’s related to printing, perhaps as part of some Samba service that you might be running (to connect to Windows printers).

Your restart looks like somebody restarted the server manually, it doesn’t look like a crash…

It could be good to stop those services (Cups, or Samba?) and see if you can get rid of all that junk in syslog, and then see if that makes a difference for your SuiteCRM problem.

Also check your general disk space with
df -h
and look for any oversized logs with
du -h /var/log