I was installing the new 2.4.20 version and it could't finish installation

I'm using

MariaDB 10.4.32
PHP Version 8.1.25

The problem I notice is when the system tries to execute the script

CREATE TABLE `0_bank_accounts` (
  `account_code` varchar(15) NOT NULL DEFAULT '',
  `account_type` smallint(6) NOT NULL DEFAULT '0',
  `bank_account_name` varchar(60) NOT NULL DEFAULT '',
  `bank_account_number` varchar(100) NOT NULL DEFAULT '',
  `bank_name` varchar(60) NOT NULL DEFAULT '',
  `bank_address` tinytext,
  `bank_curr_code` char(3) NOT NULL DEFAULT '',
  `dflt_curr_act` tinyint(1) NOT NULL DEFAULT '0',
  `id` smallint(6) NOT NULL AUTO_INCREMENT,
  `bank_charge_act` varchar(15) NOT NULL DEFAULT '',
  `last_reconciled_date` timestamp NOT NULL DEFAULT '1900-01-01 00:00:00',
  `ending_reconcile_balance` double NOT NULL DEFAULT '0',
  `inactive` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `bank_account_name` (`bank_account_name`),
  KEY `bank_account_number` (`bank_account_number`),
  KEY `account_code` (`account_code`)
) ENGINE=InnoDB AUTO_INCREMENT=3 ;

the failure is because in the newer MariaDB does not allow this line   
`last_reconciled_date` timestamp NOT NULL DEFAULT '1900-01-01 00:00:00',

so in order to make it work change it to 
`last_reconciled_date` DATETIME NOT NULL DEFAULT '1900-01-01 00:00:00',

After I did it it works, hope I can help someone.

Two innocent pieces interacting:

1. `0_audit_trail.stamp` is defined as `TIMESTAMP ... ON UPDATE CURRENT_TIMESTAMP` (FA default, used to track edit time).
2.  close_transactions() in `includes/db/audit_trail_db.inc` runs `UPDATE 0_audit_trail SET gl_seq=$seq WHERE id=...

The UPDATE only sets `gl_seq`, but MySQL auto-refreshes `stamp` as a side effect of the `ON UPDATE` clause. The `if ($row['gl_seq'] != $seq)` guard is why only some rows get hit — exactly the ones being re-sequenced.

I tried fixing it with the following change

$sql2 = "UPDATE ".TB_PREF."audit_trail SET"
    . " gl_seq=$seq"
    . " WHERE id=".$row['id'];

to:

$sql2 = "UPDATE ".TB_PREF."audit_trail SET"
    . " gl_seq=$seq,"
    . " stamp=stamp" // preserve original timestamp
    . " WHERE id=".$row['id'];

Explicitly listing `stamp` in the SET clause suppresses the `ON UPDATE CURRENT_TIMESTAMP` auto-refresh in MySQL. No schema change needed, and normal `add_audit_trail()` edits are unaffected since they already set `stamp` explicitly.

Has anyone else hit this? Kindly share your experience.

Thanks

bank_account_reconcile did NOT list the items, so I searched the GL Enquiry for transactions in case they were registered against wrong GLs.

gl_account_inquiry listed these items with the non zero values (the values I was expecting - but with extra lines)

gl_trans_view.php opened the items, displayed looking like a Journal Entry rather than the normal Payment/Deposit pop ups.

gl_journal.php?ModifyGL=yes opened into the Bank Deposit or Bank Payment editored, but all lines were of zero value, and the date was today's date.  Altering and saving resulted in the next screen saying transaction 0 was updated.

I am currently on 2.4.19 but was on 2.4.1 until a month or so ago, so this data corruption could be from a while ago.

PROPOSAL:
1) A report that cross references the various tables that store this data and reports mis-matches.
2) an editor to clean these up - either a "force" for void or similar zero everything.  I haven't worked through this yet as EOY tax reporting is less than a week away.

trial and error in attachments.php around line 37, replacing the following:

                        $type = ($row['filetype']) ? $row['filetype'] : 'application/octet-stream';
                        header("Content-type: ".$type);
                        header('Content-Length: '.$row['filesize']);
                        header("Content-Disposition: inline");
                        echo file_get_contents(company_path(). "/attachments/".$row['unique_name']);
                exit();

with

                      header( "location: " . $_SERVER['PHP_SELF'] . "/../" . company_path(). "/attachments/".$row['unique_name'] );
                exit();

works.  I don't see any security issue by passing a URL instead of a stream?

It seems they've changed their URL.

This seems to fix it:

gl/includes/db/gl_db_rates.inc

line 168 change:

$filename = "/converter/{$curr_b}/{$curr_a}/1";

to:

$filename = "/converter/{$curr_b}-{$curr_a}";

Starting line 166 this section will be:

elseif ($provider == 'EXCHANGE-RATES.ORG')
    {
        //$filename = "/converter/{$curr_b}/{$curr_a}/1";
        $filename = "/converter/{$curr_b}-{$curr_a}";
        $site = "exchange-rates.org";
        $proto = 'https://';
        $contents=file_get_contents($proto.$site.$filename);
    }

FYI: the user is Admin / Active facial year is same year as the journal entry i want to edit

Your advice is appreciated

Thanks

Hello FrontAccounting Community,

I am seeking assistance with a systemic failure where all extensions show a Red X on the "Install/Activate Extensions" page, and more critically, active extensions (like Import Transactions) are completely missing from the main menu.

This is occurring on both a fresh XAMPP installation and a HostGator installation, pointing toward a core compatibility issue rather than a permissions failure.

Environment Details

Component    Version/Status
FrontAccounting Version    2.4.x (Likely a standard release)
PHP Version (XAMPP)    7.1.1 (from the installer name)
Problem Status    All active extensions fail to load/display.

Diagnostic Steps Completed (Problem is NOT one of these)
We have systematically ruled out the most common causes:

File Permissions: The required folders (modules, _cache, company/0/attachments) have been confirmed to be writable and have sufficient permissions.

Extension Activation: The file installed_extensions.php confirms the extensions are correctly marked as active ('active' => 1).

Core Compatibility Patch #1 (Magic Quotes): The file includes\db\connect_db.inc does NOT contain the deprecated get_magic_quotes_gpc() function, meaning this common PHP 7.x patch is not needed.

PHP Config: session.save_path is working, and resource limits (max_execution_time, memory_limit) have been significantly increased.

Short Tags: short_open_tag = On has been confirmed.

The Remaining Mystery: Fatal PHP Error
Since the extensions are correctly configured to load but are failing to execute (missing menu links), the script is hitting a Fatal Error during the menu-building process. Given the PHP 7.1 version, the next most probable cause is the use of the reference operator (&) in a function declaration.

Could an experienced user please confirm the location of the core database wrapper file(s) that must be patched for PHP 7.1 compatibility, specifically by removing the & from function definitions like function &db_query(...)?

I have searched for database.inc and sql_funcs.inc and they do not exist in the expected locations in this specific FA version. If I knew the correct file name, I could apply the patch and resolve this systemic issue on both my installations.

Thank you in advance for any guidance!

DATABASE ERROR : The sales area could not be updated error code : 1054 error message : Unknown column 'descriptio' in 'field list' sql that failed was : UPDATE 0_areas SET descriptio='Global' WHERE area_code = '1' /home/sites/39b/7/7d21587bd2/public_html/dev/includes/errors.inc:235: trigger_error('DATABASE ERROR : The sales area could not be updated error code : 1054 error message : Unknown column 'descriptio' in 'field list' sql that failed was : UPDATE 0_areas SET descriptio='Global' WHERE area_code = '1' ','256') /home/sites/39b/7/7d21587bd2/public_html/dev/includes/errors.inc:261: display_db_error('The sales area could not be updated','UPDATE 0_areas SET descriptio='Global' WHERE area_code = '1'','') /home/sites/39b/7/7d21587bd2/public_html/dev/includes/db/connect_db_mysqli.inc:103: check_db_error('The sales area could not be updated','UPDATE 0_areas SET descriptio='Global' WHERE area_code = '1'','1') /home/sites/39b/7/7d21587bd2/public_html/dev/sales/includes/db/sales_groups_db.inc:71: db_query('UPDATE 0_areas SET descriptio='Global' WHERE area_code = '1'','The sales area could not be updated') /home/sites/39b/7/7d21587bd2/public_html/dev/sales/manage/sales_areas.php:38: update_sales_area('1','Global')

but in php 8.1+ it does not show Backtrace

Unhandled exception [1054]: Unknown column 'descriptio' in 'field list'. in file: /home/sites/39b/7/7d21587bd2/public_html/dev/includes/db/connect_db_mysqli.inc at line 80 exception_handler((mysqli_sql_exception Object))

How to Fix?

When doing a Report/Customer Reports, Customer Balances, and you set the dtae range for the report for example 01/03/2024 to 28/02/2025 and ask for details on the customer balances, it will include allocations made after the 28/02/2025. This creates a huge discrepancy with the aged analysis report and the Debtors Ledger for the same period.

This renders the Customer Balances useless for any period.

Please advise how we can fix this since the CA's want such a report for each customer over the financial year.

Creation of dynamic property TCPDF::$padding is deprecated in file: /home/pelham10/public_html/fa/reporting/includes/tcpdf.php at line 1172
/home/pelham10/public_html/fa/reporting/includes/tcpdf.php:185:    (TCPDF Object)->__construct()
/home/pelham10/public_html/fa/inventory/manage/items.php:173: check_image_file('../../company/0/images/Coin_2025_Town_Hall.jpg')

I use FA for years now, beside the fiscal years change (with it I always had problems) I did not encounter bigger problems.

The problem which I have now is that it refuses to act when certain actions are clicked.
For example if I want a report of profit and loss. Or when I want to enter another journal entry.
Whatever were normal actions. Now they refuse to work.

Only what I see is the that it works for a while and finally displays a yellow triangle at the top of the page.

What to do?

I'm facing slowdowns with the Direct Invoice page it might be because my database contain a lot of customers and dimensions so how can we improved to be faster.

When I open it first time after I logged in it took ~6.66s but when my session is still active and not logged out and I visit the page again it took ~1.32s.

P.S. sample database sent to @apmuthu for debugging purposes

My quick fix was to modify:

includes\errors.inc

- add line 26 : 
$bt = ($errno == E_USER_ERROR or $errno ==  E_USER_WARNING) ? "" : $bt;

- replace line 96: 
error_handler($exception->getCode(), sprintf(_("Unhandled exception [%s]: %s."), $exception->getCode(), $exception->getMessage()), $exception->getFile(), $exception->getLine());
_________________

modify includes\ui\ui_msgs.inc

- replace line 14:
error_handler(E_USER_ERROR, $msg, "","");

- replace line 19:
error_handler(E_USER_NOTICE, $msg, "","");