going from version 2018.1.3 to 2019.1.1 (database issue)

SimpleInvoices Group Forum Forums Fearless359 SimpleInvoices Discussion Group going from version 2018.1.3 to 2019.1.1 (database issue)

Viewing 15 posts - 1 through 15 (of 33 total)
  • Author
    Posts
  • #564
    ppmt
    Participant

    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?

    #568
    RRowley
    Participant

    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.

    #569
    ppmt
    Participant

    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 1 month, 3 weeks ago by  ppmt.
    • This reply was modified 1 month, 3 weeks ago by  ppmt.
    • This reply was modified 1 month, 3 weeks ago by  ppmt.
    • This reply was modified 1 month, 3 weeks ago by  ppmt.
    #574
    RRowley
    Participant

    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.

    #575
    ppmt
    Participant

    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

    #577
    ppmt
    Participant

    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.

    #665
    chris
    Participant

    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 .

    #666
    chris
    Participant

    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

    #667
    ppmt
    Participant

    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.

    #668
    chris
    Participant

    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:
    You must be logged in to view attached files.
    #670
    ppmt
    Participant

    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 3 weeks, 2 days ago by  ppmt.
    #672
    chris
    Participant

    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:
    You must be logged in to view attached files.
    #674
    ppmt
    Participant

    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?

    #675
    chris
    Participant

    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:
    You must be logged in to view attached files.
    #678
    chris
    Participant

    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)

Viewing 15 posts - 1 through 15 (of 33 total)
  • You must be logged in to reply to this topic.