Fatal error: Uncaught TypeError: Return value of Inc\Claz\Export

[RRowley]

Try this version of PdoDb.php and see if it doesn’t work across the board. Let me know the result.

Attachments:

1. pdoDb9.zip

[facer]

I totally forgot to try the new PdoDb.php
Will try the new PdoDb.php and report back to you. I already got troubles by purging mysql and installing mariadb with my other databases. At least I got all my other things running again now 😉

[facer]

Okay I tried the pdoDb9.zip and I uploaded the new php.log

and I tried the 2 commands advised in the php.log
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);

But it made no difference

• This reply was modified 3 years, 8 months ago by facer.
• This reply was modified 3 years, 8 months ago by facer.

Attachments:

1. php.log_.zip

[RRowley]

Actually this is a good result. It means that all the db patches prior to one that sets the foreign keys in the database worked. What the error is reporting is the you have some entries in your si_cron_log table that have cron_id values that do not exist in the si_cron table. These are orphan records. You are offered two ways to resolve this. One is to update these orphan records to have a cron_id that exists. The other is to delete these orphan records.

The delete option is better in this instance because these records are likely left over from when their associated si_cron record was deleted.

So, display the si_cron_log table, copy the “DELETE” command, paste it into the SQL tab and hit the “go” button. Then access SI again and see if it doesn’t complete the update for you.

• This reply was modified 3 years, 8 months ago by RRowley.

[RRowley]

OK, I missed the php.log. The DELETE and UPDATE examples shown in your previous message are examples. In the php.log file it has

FOREIGN KEY TABLE         COLUMN              REFERENCE TABLE          COLUMN     INVALID VALUE
------------------------  ------------------  -----------------------  ---------  -------------
invoice_items             invoice_id          invoices                 id         1

This is saying that you have one or more records in the si_invoice_items table with an invoice_id of 1 where there is no entry in the si_invoices table with an id value of 1. In other words, the si_invoice_item records are orphaned. My recommendation:
1) Verify that what I am saying is true.
2) Display the si_invoice_items table and go to the SQL tag.
3) Enter this command DELETE FROM si_invoice_items WHERE invoice_id = 1

Then run SI and see if it completes the update or encounters another foreign key issue.

• This reply was modified 3 years, 8 months ago by RRowley.

[facer]

It is unbelievable but true, it runs again after the command you told me to run.
If you were living close by, I would buy you a beer but I checked and saw that you are far away.
Thank you for not giving up.
I learned some new things as well.

see attachments 😉

The only thing that is left is the export to pdf

Fatal error: Uncaught TypeError: Return value of Inc\Claz\Export::setFormat() must be an instance of Inc\Claz\void, none returned in /var/www/html/simpleinvoices/Inc/Claz/Export.php:504 Stack trace: #0 /var/www/html/simpleinvoices/modules/export/invoice.php(20): Inc\Claz\Export->setFormat(‘pdf’) #1 /var/www/html/simpleinvoices/index.php(375): include(‘/var/www/html/s…’) #2 {main} thrown in /var/www/html/simpleinvoices/Inc/Claz/Export.php on line 504

• This reply was modified 3 years, 8 months ago by facer.
• This reply was modified 3 years, 8 months ago by facer.

Attachments:

1. 

   Selection_104.jpg
   

2. 

   Selection_105.jpg
   

[facer]

For the pdf export I will attach a new php.log

Attachments:

1. php.log_-1.zip

[RRowley]

Are you sure you are using PHP 7.2 or greater? The support for void type was added in 7.1 but for master-2019.2 you need to be on PHP 7.2 or greater.

Verify the version by using the phpinfo.php source in the SI directory. Change the setting of “$secure” to false and then run this by adding phpinfo.php to the end of your SI address in your browser.

For example, if you access SI by typing “simpleinvoices” in the browser address bar, type “simpleinvoices/phpinfo.php” instead. This will list all php info and you can verify the php version that it shows.

When done, be sure to set the “$secure” setting back to “true” when done so no one else can run it.

[facer]

I was always thinking I was using php 7.4.3 since it showed that in my terminal when I did:

php –version
PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies

But when I use http://localhost/simpleinvoices/phpinfo.php as you suggested it shows a different version: PHP Version 7.0.33 so I guess apache2 webserver is using a different one as the terminal shows. Time to investigate further.

[facer]

That did it I had to disable an old php apache2 module. After that all seem to be working.

Very happy with the result and thx again!

[Author]

Posts