Thank you for your report. This is a funny bug to some degree, but more than a valid and serious bug.
As a temporary workaround before release of the connector with the fix for this bug if you have the control on the code, I can suggest remove setting of SQL_ATTR_PACKET_SIZE connection attribute. If setting max_packet_size is important for you, you can add initial statement "SET max_allowed_packet=4096" to your DSN, or INITSTMT=
to your connection string.
I'm sorry, but I'm not sure what/where you mean by the SQL_ATTR_PACKET_SIZE connection attribute. Where/how do I disable that, in the MY.INI? I'm very new to MariaDB/MySQL.
Here's my current MY.INI file contents:
[mysqld]
datadir=C:/Program Files/MariaDB 10.1/data
port=3306
sql_mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
default_storage_engine=innodb
innodb_buffer_pool_size=405M
innodb_log_file_size=50M
event_scheduler=ON
[client]
port=3306
Thanks for your help and patience.
No-no, that is done in C source code of your application. Or in VB code, if it is written in VB. If you are not developer or don't have source code of the application, you won't be able to do that.
Whatever it is written in, but at the end it sets that(SQL_ATTR_PACKET_SIZE) connection attribute using ODBC API. And we have bug in processing of that attribute - we misspelled server variable name, that defines max packet size.
Anyway, it will be fixed in the next release, and hopefully the release will be built and published soon.
Thanks for the explanation. At this point, since I can use the MySQL driver, I can wait until this bug is fixed and released.
I do question how a bug of this sort has not been reported before, as I surely can't be the first to use this driver in Windows. Either that or not many are using it in Windows, or just went to using the MySql driver when they got the error.
Thanks again.
I really think this connection option is set quite rarely.
That the issue. I'm not setting it, it just tries to set it as some kind of default, and since it can't find it, it errors out.
The connector doesn't try to set max_allowed_packet on its own - only if application asks it to. And application can do that only by setting aforementioned connection option.
The fix and the testcase have been pushed to both branches
Thanks for the pretty rapid "fix". However, while the new version (1.06) now loads OK, in trying to retrieve some tables from a MariaDB 10.1.9 database, it crashes VFP with a C0000005 error. In my experience, that's the "catch-all" error code, so it probably won't be much use in finding the issue. I haven't narrowed it down yet as to what it is about the tables it doesn't like. Some tables work fine, even ones with 100K+ rows, but right now it seems to be the total field width of a row or maybe the number of fields. The ones that crash are our customer table (118 fields, 1431 bytes wide), and the inventory table (102 fields, 1701 bytes wide). I need to do more research to see exactly what's happening.
The error occurred with the 32 bit version of the driver, I have not yet tried the 64 bit version. VFP can only use the 32 bit version anyways, but it will be more than just VFP accessing the data (also will be C# .NET , ASP .NET, php and python programs, so will be a mix of 32-bit and 64-bit.
Let me know if there is any other info that may be of use to you.
Looks like the issue is with BIT type fields (1 bit). Removing the BIT fields from the table allows the connector to retrieve data from the table. If there is a bit field, it crashes.
Thanks, I will look into it