Seek advises on re-installing SuiteCRM connecting to old(current) database.

Currently at 7.7.8 with real slow performance, 9 seconds for case list… :frowning:
Doing analysis on sql request we found out that 1800 requests is needed to show and account! obviously something is wrong.

We have been using platform since sugar 5.x on Linux/MySQL then switched to IIS /Ms-SQL at 6.2
then migrated to SuiteCRM since almost the beginning of SuiteCRM, still on IIs MsSQL performance has been okay up to 7.7.x
I tried in test environment to use brand new install of 7.7.8 and connected to copy of production database.and performance is back like 7.2 time
Here are findings:1. All dropdown list needs to be redefined

  1. Needed to migrate upload directory to new code
  2. all views needs to be redefined
  3. Needed to re enter security credentials for LDAP bindings (may be because of different host server?)
  4. Obviously I will need to look after my logic hooks and other customisation performed… but

What else should I prepare time for to get the system to run properly with less disturbance to my users on the new code?

Many of those things you list will be immediately passed over if you copy the custom directory.

However, I would be very careful with that because a lot of AOP/AOW/AOS stuff was moved away from the custom directory around version 7.4, and it’s easy to mess things up. (This might even be the cause for your problem).

You run the risk of passing your problem to the new server while copying customizations, hooks, etc.

If I were you, I would first try to pinpoint more accurately what’s going wrong with your system. Can you debug the code and see what it’s doing to create all those queries? You must have some hook gone crazy, running around in an infinite loop or something. Even if you can’t solve the bug, you can know what to avoid copying into the new system.

A final thing I remembered: check if you’re getting this problem: https://github.com/salesagility/SuiteCRM/issues/1861

Regarding dropdowns: you can just look for the file: custom/include/language/en_us.lanf.php (or other language files you are using).

You will find inside all the definitions of your dropdown lists (not the layouts).

I recommend that you back things up before you touch anything. Then you could compare thje files from the old and the new system and add the missing things.

If you copy the entire file you may overwrite other needed things so I wouldn’t recommend it.

I will only copy my own custom stuff if not in “standard” install.
And I will make sure there is no problem with it… actually really simple stuff.

@pgr I do see a lot of meeting queries
but my current code is like the corrected one from github…

Before I looked I was sure this was the problem…

Thank you for your inputs all.

I’m not sure if that fix prevents the delays once the system is filled with too many lines in the database… maybe all it does is keep those lines from being generated in the first place.

So, even if your code is now fixed, you could try checking the database (that notification table). Some people fixed their systems with just this SQL in phpMyAdmin (use at your own risk):

update ‘reminders’
set deleted = 1
where deleted = 0

1 Like

@pgr … thank you!

This was the problem! after countless hours of looking around!

I am “deleting” reminders set by admin… but… does any one knows why they are there?

Serge

It was a bug. There was a hard coded date in the code, after a certain moment in history it starts generating lines in the database. It’s been fixed for a long time, but it was an ugly and serious bug. It’s so illogical it must have been one of those cases where the developer means to change it before shipping, but then forgets to, or ships the wrong version of the code…