Search options (Page 1 of 3)

Thanks for the link. It apparently solved the issue:

+++ b/core/includes/db/connect_db_mysqli.inc
@@ -10,7 +10,7 @@
     See the License here <http://www.gnu.org/licenses/gpl-3.0.html>.
 ***********************************************************************/
 define('DB_DUPLICATE_ERROR', 1062);
-define('SQL_MODE', 'STRICT_ALL_TABLES'); // prevents SQL injection with silent field content truncation
+define('SQL_MODE', ''); // well tested

So I deleted STRICT_ALL_TABLES and kept the
define('SQL_MODE', '');
Thanks for the hint. I would never have found that. However, not sure whether the STRICT check means that there is something wrong in our DB. I hope not.
and

So I guess it simply tells me that it didn't succeed in generating a valid invoice. So it doesn't bring me further to understand why I can't generate an invoice.

We are printing our official financial statements on paper with a preprinted heading. I therefore want the report to start 6-7 lines lower than the margin so it does not print upon the preprinted heading. If I edit header2.inc and put in 6-7 new lines in before the "Logo" that works fine. But it also makes the printing of the invoices start lower, which is not what we want. I can make a copy of header2.inc with the extra blank lines and call i e.g. header3.inc, bit how how do I tell FA to use header3.inc for the financial reports?

Not sure if this is the right thread. I had to create a new company fast, and as I had a copy of my principal company on a PC, I thought the easiest was to create the new company in that copy. Unfortunately I didn't create a new database, so now I have both companies in the same database (the first and the second). I don't really need the copy of my principal (first) company, so I thought the easiest would be to eliminate that, and keep the new company, I created (and which already has a lot of data in it).
Is there are way I can eliminate the first company without damaging the second? I can see that even though I have made the second company the default, the first company still has the privilege to configure the system. So I can imagine it will not be possible to delete? Or is there any other way I could do it? E.g. create a new company (preferably in a second version of FA) and migrate only the data from the second company?
I can of course keep both companies and simply ignore the first one. However, as the first company is very heavy in data and the backup is already around 80 MB (before compressing), it would be good to get rid of it (short of simply deleting all the preceding years).
I am running FA 2.4.4 on a LAMP setup.

After overriding the initial errors, I now get:
Trying to access array offset on value of type null in file: /var/www/html/frontaccounting/includes/db/connect_db_mysqli.inc at line 55
Line 55 is:
    $cur_prefix = $db_connections[$comp]['tbpref'];

Trying to install FA 2.4.8 with PHP 7.4.3 on Linux Mint 20 to go from FA 2.4.4 on Linux Mint 19. When installing I get the following error:
Trying to access array offset on value of type null in file: /var/www/html/frontaccounting/install/isession.inc at line 140
If I ignore the error, the install goes on but returns an error:
Trying to access array offset on value of type null in file: /var/www/html/frontaccounting/includes/db/connect_db_mysqli.inc at line 55
Apparently it is starts OK with an US 4 digit COA and Spanish interface. I can then upload a back-up from our working system (after increasing the parameters in the php.ini file), but it will not restore from the backup file (11 MB gzip file). I have tried doing the restore in phpmyadmin, but it turns up a blank page.
Any hint?

We have the same issue with reference numbers getting stuck. We upgraded to 2.4.4 around 6 months ago with no issues. But from about around November, the reference number to ledger entries got stuck at the same number (2615) so we have to keep track of the reference numbers to manually enter the next available number. I have tried to update to 2.4.6 on a copy, but the issue persists. Of course this is not a fatal failure, but it is annoying (and time consuming). Any suggestions?

I have no problem uploading it to the server. When I then make the restore command FA asks if I really want to proceed and it starts the restoring but stops after around 5 seconds without doing anything and with no error message.

As the backup files go on growing, I am again running into the problem that I can't restore the backup in Frontaccounting. My backup files are 4.5 (gzip) and 4.8 MB (zip) respectively. I have tried to adjust further upwards the limits in the php.ini file, but to no avail. If I go into phpmyadmin, and import the backup file to the database, it works OK. But it is a bit akward to do it that way. Any suggestions?

I can see that the income tax account is set to account type "expenses", but it makes no sense to change it to "incomes", "assets" or "liabilities". So I guess the system understands it as "expenses".