- This topic has 40 replies, 3 voices, and was last updated 1 month ago by
.
-
Posts
-
So if you select the option to start using SI, it simply returns to this screen?
What is the greatest value for the sql_patch_ref number in the si_sql_patchmanager table? If essential data is installed, you should be able to select the start using option and SI will prompt you to enter biller, customer and product.
Yes the screen just keeps returning to that screen. No matter what option I use. Attached is the sql patchmanager table screenshot.
Attachments:
Not sure what you are starting with at this point. Are you running 2019.2 to upgrade your existing database, or are you working from a empty database, no data, no tables? If running 2019.2 to upgrade existing database, did you set
zend.logger_level = DEBUGin the custom_config.php file? If using 2023 version, you would set,loggerLevel = DEBUGin the custom_config.ini file.The delete the current tmp/log/si.log file. Also, delete the tmp/log/php.log file. Now run your test. After the test, zip both log files and provide them at attachments.
Yes I am running 2019.2 to upgrade the old 2013 version. I am upgrading my existing DB. I have now set the Zend to debug. Please see attached archive file.
Export the si_sql_patchmanager table structure and data. Zip the file and attach to your response. This table contains no secure information. It’s content is basically the same on all SI implementations and indicates what patches have been applied. Also, extract the si_cron_log table structure and include in the zip file. I just need to review its structure to confirm what the log is telling me. I think you already have patch 289 applied but there is not patch record for it. And you will just need to make the dummy patch record for it. But I need to review this information to confirm this.
Hi @rrowley
Please find attached the files requested. Truly appreciate your support.Turns out there are two duplicate entries in the cron log file. If you delete these, SI should run past this point. In the si_cron_log table, delete the records with id of 223 and 231.
Hi @rrowley. I have made the changes as requested and retried to run 2019 but I get the error below:
SqlPatchManager::runSqlPatch() error. See error log for more information.Attached are the tables requested attached a fresh and the log files.
You are making progress. From what I find by googling his error, is that you exceeded the maximum number of SQL queries that are allowed within and hour. There are various solutions but before you try any of them, just try SI again and see if it completes; since an hour has passed since you got the error. If that doesn’t help, google the error and see the various solutions that those who have encountered this error have tried. This is what I googled:
User 'marvel_smp' has exceeded the 'max_questions' resource (current value: 150000)I have a new error which us below
These seem to be the only two items that have not been applied. Is there a way I can try and do this manually and see if I bypass the error?
SQL patch 318, Add foreign keys to tables. has not been applied to the database
SQL patch 319, Add set_aging field to si_preferences has not been applied to the databaseAttached are some logs.
In the error log you will find the following statement:
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 7 invoice_items invoice_id invoices id 0 invoice_items product_id products id 19 invoice_items product_id products id 20 invoice_items product_id products id 21This is telling you that there are orphaned records in your database. The table names are shown without the leading ‘si_” prefix.
The first error says there is a cron_log table record that has a cron_id field with a value of 7 that has no corresponding record in the cron table’s ID field.
The next says there is an invoice_items table record with an invoice_id field with a value of 0 that has no corresponding record in the invoices table’s ID field.
The final three errors say there are records in the invoice_items table with product_id fields containing values of 19, 20 and 21 with no corresponding records in the products table with those ID values.
You need to manually correct these issues. The first two are truly orphaned records and should just be deleted. The final three need to be reviewed. If these products should be valid, you need to add them to the products table if they don’t exist. And then you need to change the product_id of these orphaned records to have the correct value for the corresponding records with the ID’s in the products table.
The fact that these errors exist in the database, is why this foreign key support is being added at that time. Once you correct these issues, your conversion should process to completion.
- You must be logged in to reply to this topic.
Recent Comments