[RRowley]

The content of the si_invoice_item_attachments table should be empty. So DROP it, then try accessing SI again.

[RRowley]

The 500 error is most likely due to you system not being properly set up. Did you have a previous version of SI running or is this a new set up? What is the webserver package you are running? Is this a Linux or Windows system?

If you were running a previous version, can you restore to it and run correctly?

[RRowley]

First, make sure you have loaded the most current version of master_2019.2. Then, go to Settings, Inv Prefs and select the preference (probably Invoice) that you have to the invoices, quotes, etc. displaying incorrectly.

In that setting, click on the Help for the Currency Sign. Copy and paste the HTML code for the Pound currency sign to the Currency Sign field. Next put GBP in the Currency Code field. Then at the bottom of the screen set by Language and Locale to en_GB. Save these settings.

I’ve tested this and it does put the pound sign on all currency fields including the Owing at the bottom of the screen.

[RRowley]

You need to upgrade your SI version. Check out the Version Update Process topic on simpleinvoices.group.

[RRowley]

You need to use the html currency code for pound. This is explained in the help for the field settings in the Inv Prefs records. See attached picture.

Attachments:

1. 

   CurrSignHelp.jpg
   

[RRowley]

Check the tmp/log/php.log file for additional information. If info present, please zip it and attach to a replay to this message.

[RRowley]

I compared your files in zippy to mine. Pretty much the same but a couple of updates behind. You can updated to latest, but I didn’t see anything that would stop your html from rendering.

[RRowley]

Are you sure you are using PHP 7.2 or greater? The support for void type was added in 7.1 but for master-2019.2 you need to be on PHP 7.2 or greater.

Verify the version by using the phpinfo.php source in the SI directory. Change the setting of “$secure” to false and then run this by adding phpinfo.php to the end of your SI address in your browser.

For example, if you access SI by typing “simpleinvoices” in the browser address bar, type “simpleinvoices/phpinfo.php” instead. This will list all php info and you can verify the php version that it shows.

When done, be sure to set the “$secure” setting back to “true” when done so no one else can run it.

[RRowley]

OK, I missed the php.log. The DELETE and UPDATE examples shown in your previous message are examples. In the php.log file it has

FOREIGN KEY TABLE         COLUMN              REFERENCE TABLE          COLUMN     INVALID VALUE
------------------------  ------------------  -----------------------  ---------  -------------
invoice_items             invoice_id          invoices                 id         1

This is saying that you have one or more records in the si_invoice_items table with an invoice_id of 1 where there is no entry in the si_invoices table with an id value of 1. In other words, the si_invoice_item records are orphaned. My recommendation:
1) Verify that what I am saying is true.
2) Display the si_invoice_items table and go to the SQL tag.
3) Enter this command DELETE FROM si_invoice_items WHERE invoice_id = 1

Then run SI and see if it completes the update or encounters another foreign key issue.

• This reply was modified 4 years, 9 months ago by RRowley.

[RRowley]

Actually this is a good result. It means that all the db patches prior to one that sets the foreign keys in the database worked. What the error is reporting is the you have some entries in your si_cron_log table that have cron_id values that do not exist in the si_cron table. These are orphan records. You are offered two ways to resolve this. One is to update these orphan records to have a cron_id that exists. The other is to delete these orphan records.

The delete option is better in this instance because these records are likely left over from when their associated si_cron record was deleted.

So, display the si_cron_log table, copy the “DELETE” command, paste it into the SQL tab and hit the “go” button. Then access SI again and see if it doesn’t complete the update for you.

• This reply was modified 4 years, 9 months ago by RRowley.

[RRowley]

Try this version of PdoDb.php and see if it doesn’t work across the board. Let me know the result.

Attachments:

1. pdoDb9.zip

[RRowley]

Before you go to that trouble, let me look at a programmatic solution. Also, did you try the new version of PdoDb.php and did it get you past that problem. You might encounter another problem, but it is important to know if it got you past the current one.

[RRowley]

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.

• This reply was modified 4 years, 9 months ago by RRowley.

[RRowley]

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.

[RRowley]

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=2

Save the configuration file and restart your mysql database and test SI. Hopefully this will solve your problem.

Attachments:

1. 

   maria_db_config_file_locations.jpg
   

[Author]

Posts