going from version 2018.1.3 to 2019.1.1 (database issue)

[ppmt]

Hello,
It’s been a long a time since I have played with SI and wanted to go to the latest version.

I was on:

version.name                        = 2018.1.3
version.update_date                 = 20181012

and am now trying to go to:

version.name                        = 2019.1.1
version.update_date                 = 20190718

I have first done a clean install as if it was the first time I used SI and all worked well

Now I want to use my old existing database. So I restored the backup and updated the custom.config.php to point to the new database.

When I then connect to the site it wants to install the essential data (as if it was a new install!)

So I press Install and then it then gives me that error:

An error occurred while trying to import essential data

Error information should be in the error log

in the php.log I see this:

[21-Sep-2019 12:54:46 Europe/London] SystemDefaults::loadValues() error thrown: PdoDb - request(): Invalid table, si_system_defaults, specified.

that si_system_defaults is not present in my old existing database

Am I doing something wrong for the update process?

[RRowley]

The essential data prompt occurs when a database exists and can be accessed but there is no data in the si_sql_patchmanager table. Check what you are importing and make sure the database tables are populated with data.

I recommend dropping all tables and then importing your backup.

[ppmt]

I found out the problem in the end. I backed up the database and when I tried to import it again restored it I originally “ignored” a error (don’t ask!)

ERROR 1366 (22007) at line 3982: Incorrect integer value: '' for column 'fear_invoices\’.’si_products’.’default_tax_id_2′ at row 1`

when I checked the database I could see that a few of the products (about 8) had been loaded but the rest (about 20) were not. All the culprit had their ‘default_tax_id_2’ field set to ” while the loaded had ‘0’

I fixed the file to and reimport it again and after that all was good.

So I guess you are right the database did import fully and then SI assumed it wasn’t not installed!

What I don’t get is why some of the product where not set correctly. And how do you set that Tax_2 field?

Anyway the problem is solved on my side. Now I need to check that all still work as expected before switching over.

• This reply was modified 4 years, 7 months ago by ppmt.
• This reply was modified 4 years, 7 months ago by ppmt.
• This reply was modified 4 years, 7 months ago by ppmt.
• This reply was modified 4 years, 7 months ago by ppmt.

[RRowley]

I suspect it is an issue that evolved for the dataset settings over time. Can’t see what table structure was originally but at some point field altered to be INT(11) and nullable. Recommend that you check the table structure to verify that it allows NULL and then change all 0 values to NULL.

The new master_2019.2.1_beta which implements foreign keys will eliminate this problem by tying the tax id fields to the id field in the si_tax table.

[ppmt]

I will check as instructed…

I am also going to may be create another post related to pdf if I can’t find my answer in the documentation. It seems the master_2019 repo doesn’t include the library/pdf directory

[ppmt]

I updated the database to NULL and it is still working. The default value for that field is NULL.

and forget about the pdf. It does work. I was confused by the documentation that ask to check to for library/pdf
Then I saw you replaced that library by something else.

[chris]

Think i’m having a similar problem, installed SI 2019-2 master installed database and essential data etc, imported my database backup and now getting the upgrade database screen which when run gives:

SqlPatchManager::runSqlPatch() error. See error log for more information.

But i can’t find the error log. ./tmp/log doesn’t have a php.log file in it even though i’ve set error level to debug, have only got the si.log:

2019-10-20T21:01:49+00:00 DEBUG (7): Setup::init() – logger has been setup
2019-10-20T14:01:49-07:00 DEBUG (7): session_timeout loaded[15]
2019-10-20T14:01:49-07:00 DEBUG (7): init.php – frontendOptions – Array
(
[lifetime] => 900
[automatic_serialization] => 1
)

2019-10-20T14:01:49-07:00 DEBUG (7): init.php – authentication-enabled[] fake_auth[1]
2019-10-20T14:01:49-07:00 DEBUG (7): index.php – After init.php – module(] view[]
2019-10-20T14:01:49-07:00 DEBUG (7): index.php – After processing init.php for extensions
2019-10-20T14:01:49-07:00 DEBUG (7): index.php – module[] view[] databaseBuilt[1] databasePopulated[1]
2019-10-20T14:01:49-07:00 DEBUG (7): index.php – apply_db_patches[1]
2019-10-20T14:01:49-07:00 DEBUG (7): index.php – config->authentication->enabled[] auth_session->id: 1
2019-10-20T14:01:49-07:00 DEBUG (7): index.php – view[database_sqlpatches] module[options]
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – module[options] view[database_sqlpatches] action[] id[] menu[]
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After invoices/template
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After api/xml or ajax
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After extension_jquery_files
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – after custom/hooks.tpl
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – after header.tpl
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After extension_php_insert_files, etc.
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After export/export exit
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – post_load…
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After menutpl processed
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After main.tpl
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After options/database_sqlpatches.tpl
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – path[templates/default/options/] my_tpl_path[templates/default/options/database_sqlpatches.tpl]
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – After output my_tpl_path[templates/default/options/database_sqlpatches.tpl]
2019-10-20T14:01:50-07:00 DEBUG (7): index.php – At END

2019-10-20T21:01:52+00:00 DEBUG (7): Setup::init() – logger has been setup
2019-10-20T14:01:52-07:00 DEBUG (7): session_timeout loaded[15]
2019-10-20T14:01:52-07:00 DEBUG (7): init.php – frontendOptions – Array
(
[lifetime] => 900
[automatic_serialization] => 1
)

2019-10-20T14:01:52-07:00 DEBUG (7): init.php – authentication-enabled[] fake_auth[1]
2019-10-20T14:01:52-07:00 DEBUG (7): index.php – After init.php – module(] view[]
2019-10-20T14:01:52-07:00 DEBUG (7): index.php – After processing init.php for extensions
2019-10-20T14:01:52-07:00 DEBUG (7): index.php – module[] view[] databaseBuilt[1] databasePopulated[1]
2019-10-20T14:01:52-07:00 DEBUG (7): index.php – apply_db_patches[1]
2019-10-20T14:01:52-07:00 DEBUG (7): index.php – config->authentication->enabled[] auth_session->id: 1
2019-10-20T14:01:52-07:00 DEBUG (7): index.php – view[database_sqlpatches] module[options]

I’ve lost track of which version i was on beforehand as i got very confused following the status of SI, started with 2013, might have upgraded to 2018 at some point but not sure if it was the fearless version etc. :/

I love it and use it for my business but the version i had stopped working after moving to a newer server with php 7 etc on it. Spent a week following the trail from 2013 original site -> google groups -> github and finally to this site. Would love to get it working .

[chris]

Should add that the patch it is trying to run is the last one:
SQL patch 318, Add foreign keys to tables. has not been applied to the database

[ppmt]

can you check the database dump file you have (the one you imported) and check that the table si_products.

If the field default_tax_id_2 is set to “” (empty) then it is the reason it was failing for me. The solution is to update the file to set the empty field to null and the reimport the database and restart the upgrade.

[chris]

Hi, have uploaded screenshot of phpmyadmin contents. This is from how it is just now though, do i need to open the actual .sqbackup file before importing it and check it there? What can i use to open it other than importing it to a database?

Attachments:

1. 

   Untitled.png
   

[ppmt]

Is that all your product listed there? If you are like me then only a few were loaded..

I would suggest to check the sqlbackup file (it should be a text file) to make sure that the field default_tax_id_2 is really set to either null or 0 for all product.

• This reply was modified 4 years, 6 months ago by ppmt.

[chris]

Attached phpmyadmin contents from original server (where the backup came from) full of 0’s does that count as empty? Do i need to change them all to NULL instead? Can google a way to do that if thats the case.
Spotted in my playing around that its the 2016 version of SI i have on the original server if that helps anymore.

Attachments:

1. 

   Untitled-1.png
   

[ppmt]

well if all of them are really set to 0 then you have a different issue than I did. I would still check the sqlbackup file to be sure.

And are you sure you don’t have a php.log file in your tmp/log directory?

[chris]

Yup 🙁 no sign of it. I might try drop back a version or two tonight and see if i have more success. Any idea which version is 1 previous to the foreign keys being added to the database?

Attachments:

1. 

   Untitled-2.png
   

[chris]

Have dropped back to the regular fearless master version and php 7.1 and working fine, can’t get my logo to display in pdf exports though after trying all the usual suspects. Have opened a new post on that though:

PDF not displaying logo (just an empty square)

[Author]

Posts