Forum Replies Created
-
Posts
-
One thing you might try is to increase the time allowed for a query to process. In your php.ini file, find the line, “max_execution_time”, and double the value that is assigned to it and save the change. Then restart your webserver (apache) and try to list customers again.
OK, that looks normal. Please send me a zip of the Inc/Claz, modules and templates directories so I can compare them to what I have.
If the result of the previous query is LOWER_CASE_TABLE_NAMES 0, then I suspect you are running on a system that is using a case sensitive file system. So while the change I made fixes the issue you are having (hopefully), there are other issue that will be encountered.
The fix, I believe, is to set LOWER_CASE_TABLE_NAMES to 2. This performs all comparisons in lower case. Unfortunately, you have to make this change in the configuration file. You will have to find this file and add the following to it.
First, look to see if there is a section for [mariadb]. If not add this section at the end of the file. If it does exist, you don’t need to add this section.
Immediately following the mariadb section line, add the following:
lower_case_table_names=2Save the configuration file and restart your mysql database and test SI. Hopefully this will solve your problem.
Attachments:
I attached the command to use in a text file. Note that it has backticks around database related names and single quotes around strings. Also, the picture had my database name in it. The text has yours, so the command should be able to be cut and pasted into the SQL command box.
OOPS, looks like this interface doesn’t like txt files. So I zipped it.
First request is that you update to master_2019.2. It has the most current fixes. From there we see what problem exists and work to resolve it.
Check out the attached pictures and test with the new PdoDb.php file.
Attachments:
OK, hopefully I am drilling into it. It seems like for some reason, the source field is not being returned as part of the si_sql_patchmanager table. I have attached another update for the PdoDb.php file for you to test with. It will generate even more information in the php.log file. As before, put the PdoDb.php file in the Inc/Claz directory and delete the tmp/log/php.log file before you test. Then give me the new php.log file so I can drill through it.
OK, that gave me some information but not why the logic to set the update value isn’t working. So attached is a zip file for an updated version of PdoDb.php file. Extract this into the Inc/Claz directory, delete your tmp/log/php.log file and test again. Then zip the log file and send it to me.
As Bullwinkle used to say, “This time for sure…” Please try again with file in attached file. Note that I modified the attached file name but the file inside is still PdoDb.php. This change will generate more output to the php.log file but hopefully will print what I am looking for.
That didn’t catch the error. I believe my debug test was wrong and have changed it. Put the PdoDb.php file in the zip attached to this message in the Inc/Claz directory and try again. First clear the php.log file then do the test and give me the php.log from that test.
Basically, you are free to modify templates and use them in your application. There is a well defined process for this. Unless there is a bug relative to the defaults, they will remain unchanged. That’s how it stands at this point.
I’m flummoxed by this. Attached is a zip file with the PdoDb.php source in it. Put this in the Inc/Claz file same as you did for the SqlPatchManager.php file. Keep the SqlPatchManager.php change in there also. Clear your tmp/log/php.log file (can delete it). Run with these changes and send me the new php.log file. Ignore the extra pdoDb-1.zip file.
Recent Comments