Forum Replies Created
-
Posts
-
When you say you tried this loading sample data, does this mean you started with an empty database, letting SI load default configuration data and then letting SI install sample data? If this is the case, the issue if perplexing indeed.
What version of SI are you trying to upgrade from? What version of PHP are you on?
If error persists, zip the
tmp/log/php.logfile and attach it to your response.Sorry for not getting back to you sooner. Are you still stuck with this error? If so, what happens if you start with an empty database. This should load default data. I know this isn’t what you want, but it tests the process without updating any information from your existing database to just see if the process works. If it does, the problem would then appear to be data related. If it doesn’t, it is more likely configuration related.
Also, make sure the GD and INTL extensions are enabled for you PHP version. This is set in the php.ini file. To list what is enabled for your PHP version, use the phpinfo.php file in the simple invoices root directory. Edit this file and change the
$secure = true;setting to false. Then run this file in your browser. After you are through using this file, change the setting back to true.What version of PHP are you running on? My production level is 8.1 which is the minimum level required by the SI 2023 version.
The config.ini file is a template only. The custom.config.ini file is where values are actually taken from. They do not need to be the same. Each time you access SI, the keywords in your custom file are compared to those in the template. If there are keywords in the template that aren’t in the custom file, the keyword and default value is copied to the custom file. And keywords in the custom file that aren’t in the template are flagged by surrounding them with comments. This way, changes to SI config file values automatically propagate to the custom file without altering the values in the custom file.
As to the error you are getting for the non-abstract method, attach the new php.log file (zipped of course). Hopefully it contains a better description of what is going on.
I suggest you delete the php log file and try again. I expect the same error but it is worthwhile proving it. This is the error I expect in your log file:
[15-Dec-2024 22:39:55 Europe/London] SqlPatchManager::runSqlPatch() – PdoDb – query(): Execute error. See error_log.
[15-Dec-2024 22:40:08 Europe/London] PdoDb – debugger(): ALTER TABLEsi_cron_logADD UNIQUE INDEXCronIdUnq(domain_id,cron_id,run_date);
[15-Dec-2024 22:40:08 Europe/London] PdoDb – query(): Execute error.Array
(
[0] => 23000
[1] => 1062
[2] => Duplicate entry ‘1-37-2018-10-01’ for key ‘CronIdUnq’If this is the same as the new error in the php log file, then call me crazy, but I don’t think the database you are accessing with phpMyAdmin is the same that is same as the one being accessed by SI. You would then need to verify the DB name in the custom.config.ini file. I say this because as you see in the Duplicate entry error message, it shows a record found with run_date, cron_id and domain_id message with as value of 1-37-2018, 10 and 01 respectively.
Ok. Your issue is that the si_cron_log table contains records with the “domain_id”, “cron_id” and “run_date” that are duplicates. You need to use your myPhpAdmin program to find the duplicates and correct them. The easiest correction is to delete the duplicate records. If these records are needed, record to dup info record values and after the conversion, add the record back via the Recurrence option in SI.
Refer to the Extensions topic on left menu. This should explain how to make changes to your local copy of code in such a way that future updates don’t load over them.
The field validation routine obviously doesn’t allow you to type in a negative value. You can create a product for the credit with a negative amount. This will set the field to the negative value when you select that product. This works for fixed value credits but not so much for credits that are arbitrary, set based on the particular situation.
For example, I have a product, “Labor”, that is $30.00 per hour and one for “Labor (Credit)” for -$30.00 per hour. This works for me because my labor cost is fixed and hence a credit is similarly fixed.
Let me know if this work around addresses your need not just for this circumstance but on going for future situations.
I am at a loss as to why you would have an issue with a library file function that is used pervasively throughout this application. At this point, I would recommend you try reinstalling the SI application. First, following the Version Update Process on the left menu. This makes sure that everything is reinstalled. If that does not work, you might try installing a clean version of SI. This is in the Installation link on the left. Do this letting that application install the new database – you set up an empty database and SI loads the structure and required files. If this works and you can run the application, the issue likely lies in a difference in your database and its data structures. If this is the case, you should export a copy of your existing database structure, no data just structure, and the structure of the newly installed database that is working. I’ve had to do this in the past for other reasons and found that over time and updates, database field definitions have been changed but not reflected in my database. This shouldn’t happen, but it did. So the resolution was to manually alter the real database to match the structure of the test database. Once this is done, point the SI application to your live database and see if the issue is resolved.
What version of PHP are you using? This is a library error and not typically something that I can fix. You might make sure that you are using symphony libraries consistent with your PHP version.
For some reason, the PDO class in PHP is not being recognized. I have attached the following link to documentation that might help you determine what you need to do in your set up.
Recent Comments