Advance search not working on new install of SuiteCRM 7.9.8

Hello.
I did a fresh install of SuiteCRM 7.9.8 on Debian 9 (php 7.0.19-1, mysql Ver 15.1 Distrib 10.1.26-MariaDB, Apache 2.4.25) and moved my database from my old instance of SuiteCRM 7.9.4 on Debian 7. I did a maintenance rebuild and everything appears to be working correctly but not Advanced Search.
The “Perform Lucerne Index” and “Optimize AOD Index” have run as they are supposed to run.
I’ve read a number of the forum posts and the only thing I can find in the log is

[FATAL] Job runs too frequently, throttled to protect the system.
[ERROR] Unable to get proper side for link project_name_link

after fixing a date.timezone missing in the cli php.ini. I’m running log at ERROR level.
I’m not sure what else I should be checking. Any suggestions appreciated.
Thanks

In the /var/log/apache2/error.log I can see this

PHP Notice:  Only variables should be passed by reference in /var/www/suitecrm/modules/Calls/Call.php on line 295

.
Not sure if that is relevant?

I would say the PHP Notice is not relevant.

Have you copied the Index over along with your files? Maybe it just needs rebuilding:

https://pgorod.github.io/Reindex-AOD/

Make sure the permissions are ok in that directory, including the UID/GID bits which controls what permissions any new subdirectories and files will get.

I only did a mysql dump and import of the suitecrm database. So I didn’t copy the …/modules/AOD Index/Index/Index files.

From reading your linked posting there is a SuiteCRM database table AOD_index and AOD_index_event. I guess those are the ones you suggest if I copied? If they are copied in a database dump, then the answer would be yes.

In your posting (1) do a backup, this is done as a precaution?

And, I manually delete the two tables using mysql cli or phpmyadmin?

Yes, the backups of the files and of the database tables are just for precaution, if everything goes well you won’t need them.

But now I’m worried about another thing: from what I gather in your posts, if you didn’t copy the SuiteCRM directory, but just the database, and you switched versions in-between, you’re doing it wrong and you will get into trouble. Unless I am mistaken, you’re trying a migration (from one install to another) at the same time as an upgrade (from 7.9.4 to 7.9.8 ).

You should always migrate at the same version level, so either do a fresh install of 7.9.4, migrate content (and then you can upgrade to 7.9.8 ), or upgrade your old server (or a clone of it) to 7.9.8, and then migrate to a fresh install of 7.9.8.

This is important because the database also gets changes from version to version, and without the upgrade scripts they might not happen.

Thanks again @pgr.
Now you’re worrying me. :frowning:
I asked in the forums about how to do the fresh install since I was unable to get the 7.9.4 instance to run the update wizard properly. Earlier advice to migrate I think it always timed out. Anyway, it never got past the check stage with “ERR_EMPTY_RESPONSE” so I was stuck at 7.9.4. And when I tried to install php7 on Debian 7 it screwed up the server. Lucky I could rollback to an earlier snapshot.
Since it was still using old php5.6 and Apache2.2 I figured it best to move to the new platform and do the fresh install and dump the data and import.
According to @djsamson the database structures between point updates are the same so I figured I was OK to go.
The only thing that isn’t working properly that I’ve found so far (2 days) is the advanced search. Basic search works but it’s a bit a PITA using the dropdown, then clicking basic search in the first blank results page but it works.

If Daniel says there are no differences in the database between those versions, then he’s the authority, not me. I didn’t know that was guaranteed.

But your experience confirms it, if you really have no other problems.

Then don’t worry, just go ahead and try to fix the Advanced Search.

The Rebuild should do it… I hope.

Thanks again @pgr.
Should I leave the aod_index_audit and aod_indexevent_audit files or delete those along with aod_index and aod_indexevent?

Remember to only delete the rows from the tables, not the tables themselves.

I have no idea how to answer your question, I didn’t know those other tables. Maybe leave them and see what happens, then if necessary delete them and try again. all of this, supposing you have all the backups needed.

I think when you delete the folder, the entire process starts over so it becomes irrelevant whatever you did in the database. But I am not sure.

1 Like

Thanks @pgr.

I moved the Index folder, did a truncate on the aod_index and aod_indexevent tables from within MariaDB, and low and behold the advanced search works now.

> truncate table aod_indexevent;
> truncate table aod_index;

Now to delete the old Index folder and all is great!

Thanks again for your help!!

PS I didn’t touch the aod_index_audit and aod_indexevent_audit files.

Hey, have been having the same problem on Suite 7.9.9 AND previous builds.

I noticed that on a test installation with the entire installs permissions set to 777 the Advanced Search was working. When I migrated to a production site with recommended permissions it stopped working. Narrowed it down to the modules/AOD_Index/Index/Index folder. I have set ALL the contents of that folder to 777 and the Advanced search continues to work as it should. Not that happy having a folders contents set to those permissions but it is working. Worth a try?

Also for those of you that can’t find results in the Advanced search for particular modules they are enabled here index.php?module=Administration&action=GlobalSearchSettings Admin -> Global Search and if you want to index your site, go to index.php?module=AOD_Index

Cheers

@mpeet it would be much better if you opened a new thread with your issue, including all information about your system. I will answer you there.

Hey pgr, sorry, I don’t have an issue, as I said in my posting it was solved by setting permissions on the Index folder to 777 - I thought that might be relevant to someone else having the same issue?

Cheers

Hi. If you set your permissions to 777, you do have an issue, and that is not a good advice to give to others. Sorry :slight_smile:

Yes pgr, and I did say that it was an issue in my original posting, however, it may help someone in locating what the root issue is, permissions based perhaps - thats all :=]

1 Like