Forum Replies Created
-
Posts
-
Export the structure of you database, zip it and attach to a response to this topic. I need to determine if their might be other inconsistencies with what the patch process is expecting.
I’ve loaded updated library files in the latest version of master_2020. Use this and see if you still have an issue, let me know.
SI updates your custom.config.php file if it is missing tags that have been added to config.php. To do this, it renames your custom.config.php file to custom.config.php.old and then creates a new custom.config.php and loads the data in it. If the application does not have write access to the config directory, it cannot do this.
You need to make sure the application has write access to this directory. Also to the public and tmp directories.
HERE IS A REVISION OF MY PREVIOUS POST. I ATTEMPTED TO EDIT IT BUT WAS TOO LATE. SO IGNORE IT AND READ THIS
I assume the error displayed in your browser is:
SqlPatchManager::runSqlPatch() - PdoDb - query(): Execute error. See error_log.In the php.log, it is attempting to create the si_products_attributes table but this table already exists.
This update would only happen if the greatest value of the sql_patch_ref column in the si_sql_patchmanager table has a value less than 255 and if the si_products_attributes table already exists.
This inconsistency suggest your database is in an unknown state.
To remedy this, you should DROP all tables from the database and then Import the database running for SI 2011 at the time you upgraded to PHP 7.4.
After doing this, check out the content of the si_sql_patchmanager table and verify that the greatest sql_patch_ref value is less than 255 and that there is no si_products_attributes table. Or, that the greatest sql_patch_ref value is greater than or equal to 255 and the si_products_attributes table exists.
If one of these assertions is true, you can access the master_2019.2 code that you have loaded on your system and hopefully this will run correctly. Let me know if this is the case.
However, if neither of these assertions is true, do not run anything, report that here and we’ll work on it further.
I assume the error displayed in your browser is:
SqlPatchManager::runSqlPatch() - PdoDb - query(): Execute error. See error_log.In the php.log, it is attempting to create the si_products_attributes table but this table already exists.
This update would only happen if the last row in the si_sql_patchmanager table has a sql_patch_ref value less than 255 but the si_products_attributes table already exists.
This inconsistency suggest your database is in an unknown state.
To remedy this, you should restore both database and SI version to what you had running correctly for SI 2011 at the time you upgraded to PHP 7.4. After doing this, check out the content of the si_sql_patchmanager table and verify that the greatest sql_patch_ref value is less than 255. Also verify that there is no si_products_attributes table.
If both these assertions are true, then access the master_2019.2 code that you have loaded on your system.
Hopefully this will run correctly. Let me know either way.
The error you are getting doesn’t appear to come from the master_2019.2 load. I believe that you loaded the master version which isn’t supported. Use this link to get the master_2019.2 version: Master 2019.2 Zip File.
You should restore your database and clear out all file from the previous download. Be sure to keep your config/config.php and config/custom.config.php files from before the previous load.
A user has encountered this issue before. The problem is the value in the database for the si_system_defaults table on the row with the name of “Delete”, is not correct. It likely contains a Y or N, or a T or F. Change this value manually to be 1 or 0 respectively.
You have to load and successfully run the master_2019.2 update before you can load the master_2020 version. Please make sure that you process it in this order.
OK, lets just set the basics in the custom.config.ini file. Retype your lines to make sure there are no weird characters in them. Also, there is an updated Config.php file in the zip below. It checks for the false return that you are getting and shows a generic error rather stack dump.
[production] databaseAdapter = pdo_mysql databaseUtf8 = true databaseHost = yourhostsetting databaseUsername = yourdbusername databasePassword = "yourdbpassword" databaseDbname = yourdbname databasePort = 3306 authenticationEnabled = true authenticationHttp = exportSpreadsheet = xls exportWordProcessor = doc exportPdfDefaultFontSize = 12 exportPdfPaperSize = Letter exportPdfLeftMargin = 15 exportPdfRightMargin = 15 exportPdfTopMargin = 15 exportPdfBottomMargin = 15 versionName = 2020.0.12 versionUpdateDate = 20210128 localLocale = en_US localCurrencyCode = USD localPrecision = 2 emailHost = youremailsmtphost emailSmtpAuth = true emailUsername = youremailusername emailPassword = youremailpassword emailSmtpPort = yoursmtpport emailSecure = yoursecuresetting emailAck = youracksetting(true/false) emailUseLocalSendmail = youruserlocalsendmailsetting(true/false) encryptionDefaultKey = this_is_the_encryption_key_change_it nonceKey = this_should_be_random_and_secret_so_change_it nonceTimeLimit = 3600 debugLevel = All debugErrorReporting = E_ERROR phpSettingsDateTimezone = yourdatetimezonesetting phpSettingsDisplayStartupErrors = 1 phpSettingsDisplayErrors = 1 phpSettingsLogErrors = 1 phpSettingsErrorLog = tmp/log/php.log ; Logs in tmp/log/si.log. Set to the desired level for log detail. ; The lower the number, the more information will be logged. ; DEBUG(100),INFO(200),NOTICE(250),WARNING(300),ERROR(400),CRITICAL(500),ALERT(550),EMERGENCY(600) loggerLevel = DEBUG ; Explicitly confirm delete of line items from invoices? (yes/no) confirmDeleteLineItem = noChange line 45 and 46 of the Inc/Claz/Config.php file from:
$fooType = getType($config[$section]);
var_dump("gettype {$configFile}[{$section}]: {$fooType}");
to
$fooType = getType($config);
var_dump("gettype {$configFile}: {$fooType}");and run the test again.
Not sure what is happening. Your custom.config.ini parses correctly for me once I fill in valid database settings. So we need to troubleshoot to drill down to the problem. Attached is a zip file containing the Config.php file. Store this in your Inc/Claz folder over the existing version of the file. After doing this, do any action (display the login screen, etc.) and there will be information displayed at the top of the browser screen. Copy this information to a response to this this message. Show the info in a CODE section so nothing get misinterpreted.
Make a copy of your custom.config.ini file. Then obfuscate the passwords and personal info in the custom.config.ini file, and zip it. Attach the zip file to a response to this message.
Recent Comments