Stop nginx.
Export DB into SQL format as backup.
Rename the database.
Create a new database with the backup on the original db name.
Start nginx.
Check if the problem exists.

I checked on Apache 2.2.
Check the cache folder permissions if using caching. Looks like it is not allowing to store cache of php pages.
Also check the tmp/errors.log
Investigate with go_debug settings in config.php
See if the includes/session.inc file setting for secure constants need changing.
Your data on Debian 6 based FA system seems working fine after first callup.

3

(2 replies, posted in Report Bugs here)

Looks like you have an ajax timeout problem.
Checkout:
https://frontaccounting.com/punbb/viewtopic.php?pid=43737#p43737

Just tested it out. Yes the first Direct Invoice page is slow or even times out. Logged out, cleared cache and closed browser. On next login everything is fine. Looks like some server startup / mysql index recreation / updation issue. Not to worry.

Solved. Increases the Ajax timeout to 20 seconds.
Ref: https://frontaccounting.com/punbb/viewtopic.php?pid=5318#p5318
The default is 10 seconds (10000 milliseconds) in js/utils.js lines 36 to 42:

JsHttpRequest.request= function(trigger, form, tout) {
//    if (trigger.type=='submit' && !validate(trigger)) return false;
    tout = tout || 10000;    // default timeout value
    document.getElementById('msgbox').innerHTML='';
    set_mark(tout>10000 ? 'progressbar.gif' : 'ajax-loader.gif');
    JsHttpRequest._request(trigger, form, tout, 0);
};

Replacing 10000 to say 20000 or more in the two places above will do the job.
Logout of FA. Close the browser. Clear the cache and then login to get longer ajax queries of inquiry and reports.

This has been Wiki-ed.

@joe / @itronics: can we make this a setting in the config.php?

Check PM to verify GL data
What steps do you want to verify for size?

Checked out 01-01-2024 to 31-08-2024 in GL Inquiry for 1060 account and it works fine in 10 to 12 seconds.
When we go upto 30-09-2024 (ie., one more month) it times out in 12 seconds.
This did not change with memory_limit from 128M to 4G.
Looks like some script timeout or keepalive or session issue.

There is the Slim PHP micro framework - v2.64 has been tested.
SimpleAPI extension available at https://github.com/andresamayadiaz/FrontAccountingSimpleAPI ?
https://www.frontaccounting.com/fawiki/index.php?n=Devel.SimpleAPIModule
Is this the one you are using?

A lack of indices on some fields of some tables - that only speeds up processing.
If the output is because of having a single output buffer for a very large amount of data that needs to be streamed, then a file capture of the output can be implemented. @joe: any ideas?

Are you using any extensions?
Just take a full compressed backup (delete the data from the users table in the backup) from within FA and upload it somewhere and send me a PM and indicate it here.
What versions of PHP / MySQL are you using?

9

(1 replies, posted in Setup)

Assume there are 96 "Quarter Hours" in a day and proceed.

10

(40 replies, posted in Reporting)

https://github.com/apmuthu/FA24extensions/tree/master/Extensions/mail

Take a look at the php.ini setting:

intl.default_locale.

https://server.hk/blog/15807/

If mass-answering is your issue, then many satisfied users would not have been benefited here. It is not very often that anyone answers posts in the forum lately after the start of the Ukraine war. I am doing my best to keep the project alive. Checking for code updates and code commits will reveal that clearly.

Thanks to this post, I have added this solution to the wiki at the end of:
https://frontaccounting.com/fawiki/index.php?n=Main.OpeningBalances

In case my suggestions have sent you on tangents please note that all this is part of checking the possibilities as I thought might expose issues with PHP versions. The Job offers section is there for professional assistance in case the general community does not elicit a solution.

Adding a new user post was meant for another post.

I do not know of what changes PHP 8.x will have on these extensions. Also, if there is no Banking Transactions in the said list and the Journal Transactions did not suffice, the error logs with debug on should provide some pointers. If you consider my suggestions as a tangent then please seek professional assistance in the Job Offers board. Using the audit trail is another method of viewing the various SQL queries that get traversed through during it's execution.

I maintain the unofficial extensions repo as it has some third party extensions also, not officially vetted as yet to serve as a self help resource. Also I make sure that the white space in the changed code is synched with those in the core and official code base to make for ease of troubleshooting and development.

My requests on the board and its archives have not elicited any response from the original developers of the extensions till date. Nor have any users listed the way they have solved the issues at hand in the forum and in the wiki as far as I know.

Count the number of data elements and the number of headers - they appear correct herein but if there are any tabs and / or other delimiters or blank values some issues may occur based on PHP version.
This extension last worked in FA v2.4.6.
Some corrections have been made in the unofficial extensions repo for this extension.

To download this extension visit:
https://download-directory.github.io/
and paste in the github folder:
https://github.com/apmuthu/FA24extensions/tree/master/Extensions/import_transactions
and press Enter and you will get the zip file of the extension.

Use a folder compare utility like ExamDiffPro or WinDiff or WinMerge to check on the files in your official extension at FAwebroot/modules folder with that in the zip file and upload the changes in the files as listed therein.

Just checked. This has been the default since the very beginning over 15 years ago.

Duplication of posts causes deletion to avoid having to look into multiple posts.
Please take assistance of php programmers to inspect variables in the code at the point of failure where the error comes out. There is one of the forums in this board where such professional programmers exist.
I used an existing test install on Debian 6 to check out if and when the closing GL greyed out issue occurred since several code changes have been effected over time. It is not my recommendation to use Debian 6 in public facing installs.
The project admins are in Poland (@itronics Janusz) and Sweden (@joe Hunt) who are closer to your time zone and possibly have access to several platform versions to assist.
I only have as much time to assist on various issues in FA as I participate in the project only as a hobby and for teaching accounting.
I am sorry I have been of little use to solve your issue. Good luck with others helping you.

Generally when ever any issues arise with later versions of PHP/MySQL we generally regress to a known state / platform and then probe our way to a solution.

Tested with Debian 6 and MySQL 5.1 and PHP 5.3.3 and all worked well.
If adding a user was a real problem practically all major users of FA would have complained by now.
Single stepping and watch points and debug_status are the way forward.

You will have to do an investigation into it in the code given earlier by putting it watch points and logging the variables.

Which version of PHP/MySQL are you using?

Looks like the de-activation of the linked bank account is not being updated in the database presumably if there are transactions dependent on it.

This error is effected in line 87 (in current FA version) of gl/manage/gl_accounts.php.
Lines 89-94:

            elseif (update_gl_account($_POST['account_code'], $_POST['account_name'], 
                $_POST['account_type'], $_POST['account_code2'])) {
                update_record_status($_POST['account_code'], $_POST['inactive'],
                    'chart_master', 'account_code');
                update_tag_associations(TAG_ACCOUNT, $_POST['account_code'], 
                    $_POST['account_tags']);

need to succeed.

Furthermore, the table 0_bank_accounts too needs to have the inactive field set as needed and refreshed for the session variables to be updated. From line 282, the function is_bank_account($account_code) has been defined in gl/includes/db/gl_db_accounts.inc.

Hence the specific version of MySQL when queried may be returning a NULL instead of 0 for the inactive field or the get_post() part of the html response may not be of the type expected in the browser / PHP version used.

@joe: Any checks in the code that is preventing it?

Check the Trial Balances for any discrepancy and whether Credit and Debit balances tally.

You will have to make the 2024 year as the active year and then close the 2023 year.

22

(4 replies, posted in Setup)

Check for a field with no autocomplete attribute and fill it in.

@joe: will this need to be fixed for the entire codebase or is there an autocomplete default setting or ignore that will suffice??

Closing the dummy year will forward the closing balances to the new years' opening balances.

Please note that all partial transactions will be abridged into the opening balances unless the dummy year had details of individual transactions that were to be finished in the new year.

Restart webserver if php.ini settings were changed.
Optimise your database and introduce some indexes for certain fields used in the report query.
export out your database and recreate it by importing it into a new structure.

Check if negative values are allowed in the settings.