[RRowley]

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.

[RRowley]

If SI allowed you to select install database, then any errors would be in the tmp/log/php.log file. If that file is empty, then you should be able to collect data in the tmp/log/si.log file. Make sure you enabled DEBUG level logging. This is found in the custom_confi.ini file. You don’t need to start from scratch. Just enable logging, delete the old log file if it exists. Then run SI for the install. Then zip to si.log file and attach to a new message. That should help me figure out what is going on.

[RRowley]

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 = DEBUG in the custom_config.php file? If using 2023 version, you would set, loggerLevel = DEBUG in 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.

[RRowley]

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.

[RRowley]

In custom_config.php, use the following setting.

zend.logger_level = DEBUG

This will record the entire process in the tmp/log/si.log file. Run your process and see if this file contains meaningful info. That is if it shows what steps the process has gone through and where it stopped. You can zip this file and attach it to your next post. Check the tmp/log/php.log file. If it contains info, zip and attach it also. If it doesn’t have info in it, check where you default PHP log file is being stored. This is set in the PHP configuration file. That should be where PHP logs errors up to the point where the config init step is completed and SI sends errors to the tmp/log/php.log file.

[RRowley]

OK. I created a test on my development desktop. I have xampp installed with php version 8.2.12. This was set up with enabling of GD and INTL extensions. I downloaded the simpleinvoices-master_2023 version and extracted it into my xampp htdocs folder. For ease, I created a virtual host equating the simpleinvoices-master_2023 folder to master2023. I accessed master2023 from my browser and got the no database set up error. I then created an empty database. I already had a db user with full access, so I didn’t need to add this. I added the DB user, password and db name to my custom_config.ini file. I accessed the page from the browser again and got the create database screen. I accepted this and next got the essential data screen. I then chose to not install sample data and got the screen to create a biller, customer and product. I did this and was then able to create an invoice. This tells me that your issue is not with the clean install.

Can you tell me more about your directory structure; that your SI is installed underneath your document root directory, etc. The issues of not finding the non-abstract method error seems like a search path issue that your server is running into. Also, because SI is failing on the Config:init() method, the path for the application log file has not been established. This means the default log file is used. For my install, this is the C:\xampp\php\logs\php_error_log file. You should use phpinfo to determine what your default path is.

If you modify the $secure setting in the phpinfo.php file found in the root SI directory to be set to false, and then access this file from your browser, it will display all your php configuration info including the error log file path.

[RRowley]

If you start with an empty database, the structure is created using the most current structure version and then installs essential data required to start using SI. The only reason to insert sample data is if you don’t want to use the database for live purposes; just testing it out.

Once the essential data has been installed, you can begin using SI. Just create a biller, a customer and a product. The you can enter an invoice.

This is the approach to take if you are starting from scratch. On the other hand, if you need to preserve your current version’s data, you follow the upgrade path through master_2019.2. This however appears to be having problems for you. That is why I suggested letting me try and convert your current data from your historic SI to the most current level.

From what you say about your PHP version and such, you should be able to run the most current master_2023 version. However you want to proceed, let me know.

[RRowley]

Concerning latest message, SI with empty database. You need to let SI install essential data. Without it, you don’t have required information to use SI. After that step you can choose to install the test biller, customer, product info. Or you can enter these records for yourself with your data. In order to add an invoice, you must have a biller (you), a customer (the one the invoice is for) and at least one product to add to the invoice.

Now, back to your original problem. The reason 2019.2 is a required upgrade, it because that was the last version that maintained the same database changes that were required to bring original SI versions up to the fearless359 SI version, as the development of fearless359 SI diverged from previous SI versions on the maintenance path (the projects were physically separated on GITHUB.

Here is a possible way to move forward. I can make a PHP program that will simply apply the patches 2019.2 is trying to apply. However, trying to resolve any issues this program encounters becomes tricky by us having to communicate issues back and forth. If is easier if I had your data to convert. If you are up for that, I would need a full SQL extract of your starting database structure and your data. To protect your data, you can send it to me via email, in an encrypted, password protected zip file. The password could then be texted to my phone. If you are up for that, you can email it to me at admin@simpleinvoices.group. Include your email address along with the attached file and I will then send my cell number for the password to be texted to.

[RRowley]

Are you still stuck here? What is your PHP version and what SI version are you trying to upgrade to?

[RRowley]

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.log file and attach it to your response.

• This reply was modified 6 months, 1 week ago by RRowley.

[RRowley]

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.

[RRowley]

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.

[RRowley]

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.

[RRowley]

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 TABLE si_cron_log ADD UNIQUE INDEX CronIdUnq (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.

[RRowley]

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.

[Author]

Posts