three sql errors when upgrading from 2013.1.beta.8

SimpleInvoices Group Forum Forums Fearless359 SimpleInvoices Discussion Group three sql errors when upgrading from 2013.1.beta.8


Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #867

    I wanted to report three sql errors that occur when trying to upgrade from 2013.1.beta.8 to master_2019.2

    1) the table si_users needs to have a field “username” added (otherwise there is an sql error when the patches run, complaining that there is no such field: in 2013.1.beta.8 there is only the user’s email, no name field)

    2) in the table si_customers, the field “department” has to be renamed to something else, because the patches try to add that field.

    3) in the table si_invoices the default value for the “date” field was all zeros in 2013.1.beta.8 — this gives an error with the current mysql when any alterations are made to the table, so it should be set to ‘2000-12-31 00:00:00’

    With these three manual modifications to the database, the upgrade patches ran successfully.
    Maybe someone more knowledgeable than me could incorporate this in the patch process.

    Many thanks for keeping “simple invoices” alive !


    One more patch that would be needed when upgrading older si databases is to add the password constraints to the si_system_defaults table:


    Otherwise the validation pattern in the user edit form doesn’t accept any password changes.
    Enclosed is the patch update display that showed when first opening the old database with Master_2019.2
    After applying them all, the password constraints were still missing in the si_system_defaults table.


    I just performed a fresh install of the simpleinvoices 2013 beta 8 version and then performed an update to the current version of fearless359 master_2019.2 version.

    The only issue I ran into is that an error was thrown for an invalid default value for the ‘date’ field. The ‘date’ field is an existing field and defaults to, 0000-00-00 00:00:00. The fix was to change the sql_mode setting in the my.ini file and restarting the mysql service to implement the change. After this, the update process ran without incident.

    I updated the Requirements documentation on the left menu to explain how to make this change.

    While zero dates are generally frowned upon (hence the default to disallow them), they are ingrained in SI and so for now it makes sense to allow them.

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