Hi Jack,
Until now I was connecting to SQL but now I need to connect to MySQL.
I've downloaded the MySQL ODBC connector and configured it but I'm getting an error message truncated (image 2), tried SQL debug and other traces but didn't reveal the cause.
Also tried the SQLTEST1 without success (image 3).
You mention "MySQL (native)", do I have to use some other connector independent of the Windows ODBC connector?
I can see several connectors in the MySQL website but I don't want to install unnecessary stuff.

Thank you

I haven't actually tried connecting to MySQL via ODBC, since in the MySQL case, it seems more advantageous to use the native connector. So let's start with that. Unfortunately the main MySQL web page is dominated by the Enterprise Server downloads, but at the bottom of the main page you'll see a link MySQL Community (GPL) Downloads , and on the next page, select the C API (libmysqlclient), then pick the Windows Installer option. It will install the libmysql.dll (which is essentially the back end to the connector that libashmysql.dll plugs into), and also install the Workbench (the MySQL equivalent of the SQL Server Management Studio).

It will give you a choice of versions -- pick the 5.7 version. (It should work with any server version above that.)

The other piece you'll need is ASQL libashmysql.dll, which you can download the latest version from libashmysql-1.6.149-w32.zip

Hopefully that's enough to get you going. In the meantime, I'll experiment with the ODBC version.

In playing with this a bit more, I see that I may have glossed over the details of the connector installation. But in the process, I was able to successfully perform the ODBC version, basically just like you did. (I selected the ANSI version, but either one works as far as connecting goes.)

So my guess is that you don't have the latest version of the libashodbc.dll (1.6.122); if so, try downloading it from libashodbc-1.6.122-w32.zip

For the native (non-ODBC) version of the connector, you can bypass the installer (which may only install the C++ version) and just download libmysql.dll from our website at: libmysql-6.1.11-w32.zip.
(Unzip the DLL into your A-Shell bin directory.)

Well, still no joy here

Yes, since the begining, I've downloaded the libashodbc.dll version 1.6.122.0.
I switched to the ANSI driver in ODBC but still get the same error.
NOTE: This driver is 64bit, but seems to be the only one, should I search better for a 32 bit version?

Regarding the MySQL native connector, I had already the Workbench where is a connection to the destination DB.
I've downloaded the connector but the SQLTEST1 still fail with:
Using connector MySQL (native)
Loading connector and client library... [Misc param error]

Apologize for such trouble

crossed posts...

after replacing my libmysql.dll with the fresh one downloaded from your link, the SQLTEST1 still fail with the same error above (previous post).
It's sqltest1.run version 1.2(105), is it ok?

You definitely need the 32 bit MySQL connector. The problem which I didn't see at first is that the latest version of the MySQL client installer doesn't seem to install the 32 bit C connector any more. (I mistakenly thought it did, but it was because I already had a copy of the libmysql.dll in my A-Shell bin directory.) So you can either use the copy saved on our site ( libmysql-6.1.11-w32.zip), or, on the MySQL site you have to switch to the Archives area and pick the 6.1.11 version. It will put the libmysql.dll into the directory C:\Program Files (x86)\MySQL\MySQL Connector C 6.1\lib (you can copy it from there to your A-Shell bin directory if it's not in the search path).\

There is actually a newer version (you can download them via sqltst21.zip, but I don't think it will matter for this error.

Assuming you now have both the libmysql.dll 6.1.x and the libashmysql.dll 1.6.148+ in the A-Shell bin directory, my best guess is that the libmysql.dll requires some other piece of the MySQL client environment that I installed and you didn't. (But that's hard to believe if you have the Workbench installed and also if the ODBC connector test works.)

But maybe we should pivot back to ODBC - you're still unable to get that to work either? That would imply something systematic in the MySQL 32 bit client support, but that's also contradicted by the ODBC32 Data Source test connection success.

The only other idea I have is that maybe your Microsoft Visual C++ Redistributable library is different than mine and somehow works with A-Shell but not with libmysql.dll? According to Microsoft, the 2015-2022 x86 redistributable should support everything within that period, and the libmysql.dll is from 2017 so it should be included. But if your Redistributable is less than 14.36.32532, maybe you should try updating it?

If that doesn't work, can we set up an online connection so I can play with it directly?

ok, we have progress, after uninstall the MySQL Connector 64 bits, SQLTEST1 succeed to connect to MySQL
It seems that 64 bits have precedence to execute over the 32 bits version which curiously is not listed in the Add/Remove Programs option.

but in my program I'm still having problems loading the DLL, now, in the second server where the libashodbc work, I get an error regarding both libmysql.dll and libashmysql.dll, this is insane

If you can give me a hand here, it will be a pleasure to have you connected but to go directly to this server you would have to install sophos connect to configure the VPN, that's not a problem for me, but if you prefer, you can connect to my laptop and access the server from here, just let me know how and when you want to do it.

I have to fix this, but it's not listed as urgent so, if you prefer to delay this to another day/hour, no problem

It's probably going to be more efficient to connect directly to the server if I have to transfer files. Email me the details to install and configure the sophos connect and I'll see if I can figure it out this afternoon.

Ok, after much playing around on your two RDP servers, I think we're starting to make some progress...

Here's the evidence from SQLTEST2 on the .8 machine connecting via ODBC ...

The two main problems on this machine were:

1) The myodbc8a.dll file was missing (apparently required for the 8.3 version of the ODBC connector). I'm not actually sure which package installed it, but it was either the MySQL 8.3 ODBC connector or the MySQL 8.3 C Connector (both of which I downloaded and installed). The dll ends up in C:\Program Files\MySQL\Connector ODBC 8.3\myodbc8a.dll.

2) Even after that, it was failing to load the dll due to an "access denied" error. I ended up diagnosing that with the Windows Process Monitor (which you can access directly from SysInternals live). I'm still not sure what exactly the problem is, but running A-Shell in Administrator mode allowed it to connect.

So maybe you can diagnose / resolve that one.

On the Windows Server 2022 machine (.201) the initial problem that was preventing A-Shell from loading any DLLs was that it didn't have the VC Runtime installed. Once I installed that, I was able to at least run SQLTEST1 to load the DLLs. I'll go back now and see if I can figure out what other issues there are.

I got the ODBC connector working on the Windows Server 2022 also. The issue there was that you had apparently installed the 8.3 version of the ODBC connector, but that version doesn't include the 32 bit connector. (That's why it didn't show up in the list of Data Sources.) I reinstalled the 8.0.36 version and now I was able to create the Data Source and connect to it from A-Shell. And I didn't need to run as administrator either. (So it's still a mystery what that issue is on the other machine.)

What remains is to get the A-Shell native MySQL connectors working. The problem there is that I haven't produced the '8' version of libashmysql (libashmysql8.dll) for Windows yet, and the existing libashmysql.dll appears not to be compatible with the MySQL 8 connector. You can probably get around that by downloading an older version, but I'm not sure which version you need. It makes more sense for me to create the libashmysql8.dll (which we do already have for Linux). However, you can probably do everything you want with the ODBC interface. (In fact, since you're already familiar with it, it might actually make more sense. XCALL SQL should work pretty much the same with either connector, but there are subtle differences that might snag you if switching between them.)