Forum Replies Created
-
Posts
-
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.
The error indicates that SI was not able to create a custom.config.php.new file in the config directory. Check that the directory has 755 as its access (assumes non-windows system). On windows, the directory needs to read/write access for the user.
I see the error but not how it exists. I’ve attached a zip file that contains and modified SqlPatchManager.php file in it. Extract this into your Inc/Claz directory to replace the version you have. This will write some additional debug information into the tmp/log/php.log file.
First delete the tmp/log/php.log file. Then run your SI application to replicate the issue. Assuming it fails the same way, zip the tmp/log/php.log file into a zip archive. You can then upload the zip archive to a response on this forum and I’ll look to see if I have any idea what is going on.
I’m assuming that you changed the defaults to the values I asked you to use. That being the case, no errors in php.log and the si.log content shows a normal execution of the customer list request.
First thing to do is while this command is executing, take a look that the public/data.json file. You should see your customer information in it.
Assuming that is the case and it looks good, I’d like you zip your SI directory and attach it to a reply to this message. The zip file will be too big if you include all directories, plus the config directory contains personal info that should not be shared. So I have attached a picture that shows what directories and files to include. Using this, I can compare what you have with what I have to see if for some unknown reason, you have some different files than you should.
It is a long shot, but I’m not sure what else to suggest at this point.
Attachments:
This isn’t unexpected. Print use the template setting whereas the PDF uses margin and font settings from the custom.config.php file.
There should be information in the tmp/log/php.log file. Please provide this. Also, in your database check the structure of the si_sql_patchmanager file and verify that the sql_id field exists.
In your config/custom.config.php file make sure you have the following settings:
debug.level = All debug.error_reporting = E_ALL & !E_DEPRECATED zend.logger_level = DEBUGThe debug settings are probably already set this way. But if not, will cause runtime errors to be reported in the tmp/log/php.log file.
The zend.logger_level setting will have a lot of debug information to written to the tmp/log/si.log file.
If your problem still exists, zip these files together and attach to a message added to this thread.
You should load master_2019.2. Your PHP version is better served by this version and brings you up to the best, most currently supported version.
The error is explicit. There are values in the cron_log table where the cron_id is set to 2 and to 3, but there are no entries in the cron table with an id of 2 or 3. Two options are provided. Change the cron_id in the those cron_log records to a value that does exist in the cron table or delete those records.
The update command:
UPDATE si_cron_log SET cron_id = 6 WHERE cron_id IN (2,3);
will set the cron_id to 6 for these records. Or the delete command:
DELETE FROM si_cron_log WHERE cron_id IN (2,3);
will delete these orphaned records.I recommend the delete command. These records probably were associated with cron table entries that you deleted in the past and the history in the cron_log table was not cleaned up.
To either update or delete the records copy the command, go to the phpMyAdmin console and do:
1) Access the cron_log table
2) Select the SQL tab
3) Select the Clear button to clear the default content in the text box
4) Paste your copied command into the Run SQL query text box
5) Finally select the Go button to execute the command.At this point, the orphaned records should not be orphaned/exist any more.
I recommend that you delete the content of the tmp/log/php.log file before accessing SI again in case there is another error, so it will be at the top of the file.
Great find. Just updated master_2019.2 version (v2019.2.28) on github to use the
SiLocal::dbStd(...)fix on both Itemized and Total style invoice unit prices. Also found and fixed an issue of Total style invoice handling of more than one tax item per line item used. The 2nd and on tax items we being ignored.Change any occurrence of
<td colspan="6"><br/></td>
to
<td colspan="6"> </td>In the case of
<td colspan="6"> <br/> <br/> </td>to
<td colspan="6"> </td> <td colspan="6"> </td>My test shows both the printer render and the PDF render honor this change whereas the PDF render ignores the
<br/>value in a table item definition.Is there an error in your tmp/log/php.log file? Also, check your database for the invoice_items with the greatest value (click on “id” sort once for low to high and then again for high to low). What does this show in the “invoice_id” field? The value in the “id” field contains the invoices table. There has been an issue in the past, where the “invoice_id” gets set to a zero value and so doesn’t show with the invoice., If this is the case, you can manually change the value in the database to fist the unattached invoice item. I would then suggest you perform a clean install of the current version of SI. By clean install, I mean the following:
1) Rename your current SI directory.
2) Download the master_2019.2 SI zip file from github.
3) Unzip the content of the downloaded zip file. Make sure you brows to the root directory for your web applications and then name the folder that will be unzipped to, to the name of your original SI directory renamed in step 1.
4) Copy the config/custom.config.php file from your renamed SI directory (step 1) to the config directory of the newly restored file path.At this point, you should be able to access your SI app. See if the problem you experienced has been fixed. Note that I assume that you reattached (so to speak) the invoice_items record(s) orphaned in the database to their associated invoices record(s). The verification that this issue has been resolved is that you will see invoice items defined for new and existing invoices properly associated with the invoice.
Let me know how this turns out.
Recent Comments