Search options (Page 217 of 247)

Please pm me your backup from within FA for the said company. Also attach your config.inc.php file after deleting the db password.

Looks like it is a clear case of either some new variables with backward compatibility options not conforming to your specific choices or a database schema incompatibility. The latter would be so if you have been using FA for quite some time and have been incrementally upgrading it as versions change.

State whether you are using Linux or Windows or Mac and the webserver, php and mysql versions. Will try to hammer out a sql that you can restore to get it working. Also please check the charset and collations used.

There are some errors in the Norweigian COA - one extra field is present there and some are mis-ordered besides some default diffs. Attached are the corrections that may be taken into the appropriate package in the FA repo.

Lines 363-370 of sales/includes/sales_db.inc:

    $sql = "SELECT parent.*
            FROM
                ".TB_PREF."$par_tbl parent
            LEFT JOIN ".TB_PREF."debtor_trans_details trans 
                ON trans.src_id=parent.id
            WHERE
                trans.debtor_trans_type=".db_escape($trans_type)
                ." AND trans.debtor_trans_no=".db_escape($trans_no);

This file was last changed in 2011-02-14.
No significant changes since v2.3.14 (2013-01-18) in the sql schema for the US standard 4 digit Chart of Accounts.

What Chart of Accounts are you using? Compare with the current one and see if there is any significant difference that might cause this kind of trouble.

Take a backup zip of your company's database and check.

Try upgrading directly to v2.3.18+Git.

Make sure that php5-curl and php-xmlrpc have been installed

can be latin1_unicode_ci too or latin_swedish_ci - but keep all the string fields and db collations the same.

Check in Firefox browser with java plugin enabled.
Also some temp or cache folder may not have write access by the webserver user.

Unfortunately, despite my having put up the code both here and in my personal repo, the official repo does not want to get update the package as it is considered vulnerable.... The rationale here is possibly to retain a non working package for users to hack it themselves rather than a partially hacked version that will still require hacking albeit a lot less and yet usable.

The following is declared inside the function set_global_connection($company=-1) in includes\db\connect_db.inc:

$db_duplicate_error_code = 1062;

The said error is triggered when the $db_error matches the above in function frindly_db_error($db_error) in includes/error.inc. The phrase frindly is used here instead of the more intuitive spelling friendly.

The function frindly_db_error is called in function check_db_error also in the same file includes/error.inc, which displays all other errors than this duplicate error.

The textcart extension may be what you need.

Make the database and tables latin1 and the columns default collation as latin1_general_ci or latin1_swedish_ci  but it should be uniform throughout. Alternatively, make everything utf8 and collation utf8_general_ci which is the default recommended type.

It might be easier to take a backup of the sql, edit the sql and then restore it. The database collation and charset must be done outside of FA.

Yes, it is because your initial install may not have proceeded correctly. Manually create it from the sql in the extension.

check the error log and / or turn on $debug=1; in the config.php

https://frontaccounting.com/fawiki/index.php?n=Main.Usage

https://frontaccounting.com/fawiki/index.php?n=Main.ExtensionList

https://github.com/apmuthu/frontaccounting/tree/master/extensions

Joe, will need to clarify on the FA comment in:
http://wiki.xtronics.com/index.php/Linux_accounting