SimpleInvoices Group Forum › Forums › Fearless359 SimpleInvoices Discussion Group › going from version 2018.1.3 to 2019.1.1 (database issue)
- This topic has 32 replies, 3 voices, and was last updated 3 years, 7 months ago by chris.
October 21, 2019 at 12:50 pm #681
for the php.log file what does the custom.config.php contains? Here is mine
debug.level = All debug.error_reporting = E_ERROR phpSettings.date.timezone = Europe/London phpSettings.display_startup_errors = 1 phpSettings.display_errors = 1 phpSettings.log_errors = 1 phpSettings.error_log = tmp/log/php.logOctober 21, 2019 at 11:40 pm #685
Will try upgrade again tonight, version I’m on just now uses the config. file instead of the custom.php file. Everything works fine but the export to pdf, finally found where the log files were being saved (root of the cpanel user directory) and found problems listed in the above new post. Will try upgrade again and see if it complains about something else instead. I have a suspicion I’ll get it upgraded properly and still not have working pdf export due to something else 🙁October 21, 2019 at 11:56 pm #686
Finally got something to work on……..no idea what to do with it though 😀 was a late night though and an early morning. Will maybe digest it better later in the day:
[21-Oct-2019 23:51:52 America/Los_Angeles]
Unable to apply patch 318. Found foreign key table columns with values not in
the reference table column. The following list shows what values in foreign
key columns are missing from reference columns.
There two ways to fix this situation. Either change the row columns to reference
an existing record in the REFERENCE TABLE, or delete the rows that contain
the invalid columns.
To do this, the following example of the SQL statements to execute for the test
case where the ‘cron_log’ table contains invalid values ‘2’ and ‘3’ in the
‘cron_id’ column. The SQL statements to consider using are:
UPDATE si_cron_log SET cron_id = 6 WHERE cron_id IN (2,3);
—- or —-
DELETE FROM si_cron_log WHERE cron_id IN (2,3);
FOREIGN KEY TABLE COLUMN REFERENCE TABLE COLUMN INVALID VALUE
———————— —————— ———————– ——— ————-
cron_log cron_id cron id 2
cron_log cron_id cron id 3
cron_log cron_id cron id 4
cron_log cron_id cron id 5
cron_log cron_id cron id 6
cron_log cron_id cron id 7
cron_log cron_id cron id 8
cron_log cron_id cron id 9
cron_log cron_id cron id 10
cron_log cron_id cron id 11
cron_log cron_id cron id 12
cron_log cron_id cron id 13
cron_log cron_id cron id 14
cron_log cron_id cron id 18
cron_log cron_id cron id 30
cron_log cron_id cron id 31
cron_log cron_id cron id 35
cron_log cron_id cron id 37
cron_log cron_id cron id 41
expense customer_id customers id 0
expense invoice_id invoices id 0
[21-Oct-2019 23:51:52 America/Los_Angeles] SqlPatchManager::runSqlPatch() – SqlPatchManager::prePatch318() = Unable to set Foreign Keys.
[21-Oct-2019 23:51:52 America/Los_Angeles] PdoDb destruct – incomplete transaction – rollback performed.October 22, 2019 at 12:05 am #687
Can i just delete the cron tables, upgrade the database then re-import the cron tables?October 22, 2019 at 1:12 am #688
cleared everything in the cron-log as well as a couple of empty fields in expenses, database was upgraded. Still no logo on pdf export though, latest version of fearless, php 7.2, formatting is there now just a red cross where the logo should be. No errors in php error log.October 22, 2019 at 1:21 am #689
Can i ask what versions of everything you are using so i can try and match it here and see if it works?October 22, 2019 at 2:31 am #690
Glad you got it sorted.
For the PDF I feel for you. It is not as easy as one would think to export to PDF. I have been struggling myself with its limitations.October 22, 2019 at 2:41 am #691
Have you not had any luck getting the pdf export to work?October 22, 2019 at 2:51 am #692
No PDF export does work for me. The issue I had was my templates would not display properly with things all over the place.
I found that mpdf which Richard is using has some limitation with some CSS attributes.
Once knows the templates can be adapted
On my side I am using a bit of strange config.
I have a docker container running:
– linux Alpine rev 3.10.2
– PHP 7.3.9 with PHP-FPM
– Nginx 1.16.1
in another container I have Mariadb (rev 10 I think)October 22, 2019 at 7:41 am #693
Hmmmm, i’m not sure my setup would be comparable,
-cent os 7 hosted on godaddy vps
-PHP 7.0-7.2 with PHP-FPM (tried them all with different current SI versions)
Is there anyone else that uses this forum? Appreciate your help but don’t think we’ll get much further due to the setup differences. I can’t even find anymore error messages to fix now 🙁October 22, 2019 at 7:44 am #694
Richard seems to be away at the moment. He is really the one that would be able to help you.October 22, 2019 at 8:05 am #696
That sounds about right for my luck 😀 😀 😀
As a side note: do you have a lot of invoices in your install and is it slow to load the invoices page as a result of that? Mine takes a good 30 seconds to login or go back to the invoices pages from elsewhere. I remember there being a fix for the original involving changing the database type (not sure how accurate that is but was definitely something involving phpmyadmin) but would’t think that a good idea without checking as it could wreck everything the sql patches have done during upgrades.October 22, 2019 at 8:13 am #697
I have about 200 invoices I think. It can be a bit slow as well but since I am only testing it at the moment it is not on the fastest machine. It takes about 10 seconds for me to load the invoices pagesOctober 22, 2019 at 8:18 am #698
Hmmm, i’m on 4440. Been using it since 2012. Might be an idea to wipe out the old invoices below 4300 or so. I’ve got digital copies of them all in PDF….although if i can;t get this working again i might have to just look for something else. Quite nostalgic about SI though so going to keep at it as long as possible.October 22, 2019 at 12:06 pm #699
yes that is indeed a lot but I am not sure that anything can be done on the database side. I mean Mysql/Mariadb are very efficient database that can handle much more request that 4440 query.
I would think it is the processing of these queries that takes a lot of time
- You must be logged in to reply to this topic.