Forum Replies Created
-
Posts
-
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.
In the Requirements link to the left, is a requirement to make your database allow zero dates. Not having done this might be the cause of your problem. Here is that requirement:
Make sure that zero dates are allowed in your database. Do this by setting “sql_mode=” in the my.ini file. For reference, make the current setting for this value into a comment by adding a # at the front of the line. An example of what this line might be set to is, sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION.
You lost me with the www-data. On my windows 10 development system, the windows permissions give full control to my administrative user same as any other windows folder. However, if I look at the folders through the Git Bash window, I see the 755 for window permissions on all directories including tmp and public.
I modified the Inc/Claz/Config.php file to catch the error when the new file is opened rather than when the attempt is made to write to it. This doesn’t fix your error, but kills the request and reports the error where it occurs.
Try this to verify error occurs at attempt to open the new file for write access. If not there, then the resource handle is being corrupted after being opened and that information would be helpful.
Recent Comments