The fix for Bug 611936 is the test that is now failing for you: It attempts to store 128-bit numbers into the database and read them back out. Although it's intended to find a problem with libdbi, that shouldn't be the case on MSWin because the bug doesn't manifest there. It's also strange that the check passes for SQLite3 but not for MySal. 

Your FreeBSD machine may well have the libdbi problem, or there may be a MySql problem. Can you "save as" to SQLite3 on the BSD system?

One other possible source of your problem is MySql's case sensitivity: It doesn't like uppercase characters in object names, so if you named your database (for example) Gnucash instead of gnucash, it will fail.

Thanks you very much.
About FreeBSD machine libdbi issue.
Work fine.
1. Create new account and add some transactions and save as to SQLite3,
   And close GnuCash, Reopen GnuCash, All transactions is OK.
2. Copy exist (current a lot of transactions) sqlite3 file from windows to FreeBSD
   And open, add transactions, close, reopen, All transactions is OK also.

About MySQL server, I created database's name is lowercase(eg:gnucash).
 So it is not root cause I think.
 But the database is empty, Is it OK?

Note: I make sure MySQL server connect-able on windows, tested by mysqlviewer.
Thanks you a lot.

OK. Please try again to save as your MySql database, and quit gnucash immediately after you get the libdbi dialog box. Run `tail /tmp/gnucash.trace` and post the output.

Thanks you very much.
I had been try it.
But not a /tmp/gnucash.trace file generated.

So I tried under procedure
Round 1: shell> gnucash --logto /tmp/gnucash.trace
  /tmp/gnucash.trace not exist, But I saw under error message.
  (gnucash:6950): gnc.backend.dbi-WARNING **: [conn_test_dbi_library()] Test_DBI_Library: Create table failed

(gnucash:6950): gnc.backend.dbi-CRITICAL **: gnc_dbi_unlock: assertion `dbi_conn_error( dcon, NULL ) == 0' failed

(gnucash:6950): gnc.engine.sx-CRITICAL **: gnc_sx_get_sxes_referencing_account: assertion `sxactions != NULL' failed


Round 2: shell> gnucash --debug > tmpfile
On console, I saw under error message.
qof.engine-INFO: [qof_event_generate_internal] id=1 hi=0x80b517a80 han=0x8012f964b data=0x0
qof.session-INFO: [qof_session_load_backend]  selected GnuCash Libdbi (MYSQL) Backend
gnc.backend.dbi-INFO: [mysql_error_fn] DBI error: 1044: Access denied for user 'gnucash'@'%' to database 'gnucash'

gnc.backend.dbi-INFO: [mysql_error_fn] Note: GbcDbiSqlConnection not yet initialized. Skipping further error processing.

(gnucash:62543): gnc.backend.dbi-WARNING **: [conn_test_dbi_library()] Test_DBI_Library: Create table failed
qof.session-INFO: [qof_session_begin] Done running session_begin on backend

It look like privileges issue. So I tried.
shell> mysql -h [server] -ugnucash -p
I can connect to MySQL server by "gnucash" user.
Later, I use "GRANT ALL" turn on all privileges, and save as again.

It work !! I can save data to SQL server !!

The issue is privileges problem, Not "The library "libdbi" installed on your system doesn't correctly store large
numbers."
The error message confuse me...
Can fix the error message for real reason?

I have 2 addition question.
1.Can modify SQL connect port? Because firewall block connect(port) in company.
2.Support SSL encryption SQL connect in the future? Because secure data.

Thanks you a lot.

Yeah, I just realized that that would be the first error one would get for permissions; I'll fix that soon so that the right error gets raised.

I'm reopening this bug and changing its summary to remind me.

I think that you can set the port by adding it after the hostname, separated by a colon (e.g., foo.myhost.com:1234). The protocol is set by mysql, not by us. If you need security, set up an ssh tunnel (which will also let you evade your company's firewall if the hostname trick doesn't work).

Thanks you a lot.
I had been try under...
1.foo.myhost.com:1234 and firewall forward ports:  couldn't work. I don't know why.
2.ssh tunnel work fine, I can use GnuCash in my company :D
  The idea could solve port block & security issue.

Now, MySQL & PostgreSQL native support SSL connect, If GnuCash support it also, it is good I think :p

Thanks GnuCash team a lot.

*** Bug 645554 has been marked as a duplicate of this bug. ***

Sorry, the library we use for sql database access (http://libdbi.sourceforge.net) doesn't support ssl AFAICT, so we're not going to be able to help with that.

Thansk answer.
I understood. :p
If libdbi could support SSL, GnuCash support SSL also.
I must be waiting libdbi.

Thanks you a lot :D

Created attachment 196848 [details] [review]
Distinguish test failure from failure to test in conn_test_dbi_library()

This patch applies to 2.4.7.

In gnc-backend-dbi.c: delegate responsibility for setting Qof backend error and message from gnc_dbi_sqlite3_session_begin() to conn_test_dbi_library(); use ERR_SQL_DBI_UNTESTABLE if any preliminary test steps fail, or ERR_SQL_BAD_DBI if at least one main test steps fail.

Define ERR_SQL_DBI_UNTESTABLE error code and message.

Comment on attachment 196848 [details] [review]
Distinguish test failure from failure to test in conn_test_dbi_library()

Consider this instead:

typedef enum
{
    GNC_DBI_PASS = 0,
    GNC_DBI_FAIL_SETUP,
    GNC_DBI_FAIL_TEST
} GncDbiTestResult;

return that from conn_test_dbi_library() and send the appropriate event in a switch. No travelers and no gotos.

I considered that, but elected to use delegation and gotos as the lesser of two evils in comparison to a copy/paste switch block. The gotos seemed justifiable given prior art in gnc-backend-dbi.c.

In any case, I'm perfectly content to re-wicker the patch under house rules.

The existing gotos are for consolidating freeing resources, which is reasonably idiomatic when you are running through a bunch of tests like that. 

One of your two labels is a no-op; just calling "return retval" where you "goto exit" does the same thing and is clearer. The "incomplete" label encloses a condition and makes the calls that use the traveling parameter, so it's clearer to return GNC_DBI_FAIL_SETUP and let the calling function send the messages -- especially since the calling functions are mostly running tests (of which this is one) and sending messages. (Another way to avoid the "goto incompletes" would be to wrap the second block in an else and then just test retval as you already do:

     if ( result == NULL )
     {
         PWARN("Test_DBI_Library: Failed to insert test row into table" );
         retval = FALSE;
     }
     else
     {
         dbi_result_free( result );
         gnc_push_locale( LC_NUMERIC, "C");
         result = dbi_conn_query( conn, "SELECT * FROM numtest" );
         if ( result == NULL )
         {
             const char *errmsg;
             dbi_conn_error( conn, &errmsg );
             PWARN("Test_DBI_Library: Failed to retrieve test row into table: %s",
             errmsg );
             result = dbi_conn_query( conn, "DROP TABLE numtest" );
             retval = FALSE;
          }
      }
      if ( retval == FALSE )
      {
          qof_backend_set_error( qbe, ERR_SQL_DBI_UNTESTABLE );
          qof_backend_set_message( qbe, "DBI library large number test incomplete" );
          gnc_pop_locale( LC_NUMERIC )
          return retval;
      }
) but I think that the three-state return is clearer.

I noticed while writing that that I missed popping the locale in the event of a retrieve failure, so I added it in to the example.

Roger the copy/paste problem. There's a lot of it in gnc-backend-dbi, mostly to customize the messages. It could be done better, but there are much bigger problems elsewhere.

Created attachment 196858 [details] [review]
Distinguish test failure from failure to test in conn_test_dbi_library()

This patch applies to 2.4.7.

In gnc-backend-dbi.c, accept enumerated result from conn_test_dbi_library(), then throw ERR_SQL_DBI_UNTESTABLE if the test setup failed, or ERR_SQL_BAD_DBI if at least one test case failed.

Define ERR_SQL_DBI_UNTESTABLE error code and message.
Define GncDbiTestResult enumerated type.

(In reply to comment #13)
> The existing gotos are for consolidating freeing resources, which is 
> reasonably idiomatic when you are running through a bunch of tests like
> that.

Fair enough.

> [patch analysis, example]

Thanks for giving me that insight into your thought process.

> I noticed while writing that that I missed popping the locale in the event of a
> retrieve failure, so I added it in to the example.

I did not include this fix in attachment 196858 [details] [review].

> Roger the copy/paste problem. There's a lot of it in gnc-backend-dbi, mostly to
> customize the messages. It could be done better, but there are much bigger
> problems elsewhere.

The feeling is a familiar one to me.

Review of attachment 196858 [details] [review]:

Made a couple of editorial changes (GNC_DBI_PASS != result -> result != GNC_DBI_PASS, changed error messages to report the backend).
Committed to trunk and 2.4

I want to migrate to sqlite but when i try to save as sql I am also getting this error:

GnuCash could not complete a critical test for the presence of a bug in the "libdbi" library. This may be caused by a permissions misconfiguration of your SQL database. Please see https://bugzilla.gnome.org/show_bug.cgi?id=645216 for more information.

tail /tmp/gnucash.trace
* 18:51:07  CRIT <gnc.backend.dbi> [sqlite3_error_fn()] DBI error: 13: database or disk is full
* 18:51:07  WARN <gnc.backend.dbi> [conn_test_dbi_library()] Test_DBI_Library: Create table failed

my disk is not full. in fact i have 128G available in my home dir which is where i want to save it.

arch linux
libdbi 0.9.0-2
libdbi-drivers 0.9.0-2
gnucash 2.6.11-2

Reassign version to 2.4.x so that individual 2.4 versions can be retired.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=645216. Please update any external references or bookmarks.