Server: Windows 7 SP1 64-bit, MariaDB 10.3.9
Client: Windows 7 SP1 64-bit, .NET 4.6.1

Thank you for your report. In the trace there is the error in the query execution. That is probably main bug here. Probably your application incorrectly interprets or doesn't process the error and calls SQLMoreResults. It still not the reason for the connector to crash, though.
Strange that DM didn't return some sort of "wrong commands sequence" error on such call. I'd expect that. But apparently I am wrong.

Yes, the trace says SQL syntax is incorrect. The problem is that an AccessViolationException is thrown, which is unexpected, instead of an OdbcException.

On the .NET side, all I'm doing is the below, nothing else.

try

{

    await Connection.OpenAsync().ConfigureAwait(false);

    await cmd.ExecuteNonQueryAsync().ConfigureAwait(false);

}

catch (Exception exception)

{

    // Log issue...

}

finally

{

    Connection.Close();

}

Strange, I cannot re-create execution failure
odbc_unicode -d 563c-4a00 ENTER SQLExecDirectW
HSTMT 0x00BF80D8
WCHAR * 0x004FBF80 [ -3] "\ d\ aSELECT 1;\ d\ aSELECT 1\ d\ a\ 0"
SDWORD -3

odbc_unicode -d 563c-4a00 EXIT SQLExecDirectW with return code 0 (SQL_SUCCESS)
HSTMT 0x00BF80D8
WCHAR * 0x004FBF80 [ -3] "\ d\ aSELECT 1;\ d\ aSELECT 1\ d\ a\ 0"
SDWORD -3

Are you sure that latest connector version is used? Could you please verify that?

Perhaps that is because you are using Async functions. But I've got it - that happens inside .Net

Yes, definitely "MariaDB ODBC 3.0 Driver", version 3.0.9 (and 3.0.8 was the same.)

Same happens without async, calling Open() and ExecuteNonQuery():

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

   at System.Data.Common.UnsafeNativeMethods.SQLMoreResults(OdbcStatementHandle StatementHandle)

   at System.Data.Odbc.OdbcStatementHandle.MoreResults()

   at System.Data.Odbc.OdbcDataReader.NextResult(Boolean disposing, Boolean allresults)

   at System.Data.Odbc.OdbcDataReader.Close(Boolean disposing)

   at System.Data.Odbc.OdbcDataReader.Dispose(Boolean disposing)

   at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader, Object[] methodArguments, SQL_API odbcApiMethod)

   at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader)

   at System.Data.Odbc.OdbcCommand.ExecuteNonQuery()

Silly me - the version can be seen in the trace in the driver signature in the error text.

That is strange, that after execution error .Net calls SQLMoreResults. Async was my guess of the reason. You proved it was wrong.

Now, I don't really have ideas why the query execution fails for you, but not for me. From the odbc point of view my testcase identical to yours. Would it still fail if all statement are put in single row without any new row characters?

Yes, same failure with:

SELECT 1;SELECT 1;

Forgot to mention, that I cannot reproduce crash in the SQLMoreResults either.
And I am not sure how to proceed further. I'll probably try to get win7 somewhere and test on it.
Also, could you provide standalone .Net test? I am actually not sure if that can help, I am just a bit despair.

I was able to reproduce the same exception in my environment.

I got fresh system Windows Server:
OS Name: Microsoft Windows Server 2022 Standard
OS Version: 10.0.20348 N/A Build 20348

Then install:

• https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-6.0.415-windows-x64-installer
• https://dotnet.microsoft.com/en-us/download/dotnet-framework/thank-you/net481-developer-pack-offline-installer
• https://dlm.mariadb.com/3293262/Connectors/odbc/connector-odbc-3.1.19/mariadb-connector-odbc-3.1.19-win32.msi

Started DB in docker like this:

docker run -d -p 3306:3306 -e MARIADB_ROOT_PASSWORD=Supercalifragilisticexpialidocious mariadb:11.1.2

• Get test source from github: git clone https://github.com/tomasvladik/reproIssuesOdbc-247.git
• update file reproIssuesOdbc-247/MyQueryRunnerTests.cs - line 21 your docker database IP ADDRESS
• Intitialize nuget system: dotnet new nugetconfig
• execute the test: dotnet test .\reproIssuesOdbc-247\demo.ODBC-247.csproj --runtime win-x86

Actual result:

Failed Execute_AgainstRealDb [1 s]

  Error Message:

   System.AccessViolationException : Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

  Stack Trace:

     at System.Data.Common.UnsafeNativeMethods.SQLMoreResults(OdbcStatementHandle StatementHandle)

   at System.Data.Odbc.OdbcStatementHandle.MoreResults()

   at System.Data.Odbc.OdbcDataReader.NextResult(Boolean disposing, Boolean allresults)

   at System.Data.Odbc.OdbcDataReader.Close(Boolean disposing)

   at System.Data.Odbc.OdbcDataReader.Dispose(Boolean disposing)

   at System.Data.Common.DbDataReader.Dispose()

   at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader, Object[] methodArguments, SQL_API odbcApiMethod)

   at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader)

   at System.Data.Odbc.OdbcCommand.ExecuteReader(CommandBehavior behavior)

   at System.Data.Odbc.OdbcCommand.ExecuteReader()

   at OdbcTest.MyQueryRunner.<LoadData>d__1.MoveNext() in C:\GIT\reproIssuesOdbc-247\reproIssuesOdbc-247\MyQueryRunner.cs:line 38

   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)

   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)

   at OdbcTest.MyQueryRunner.ExecuteQuery(String connectionString, String query, TimeSpan queryTimeout) in C:\GIT\reproIssuesOdbc-247\reproIssuesOdbc-247\MyQueryRunner.cs:line 28

   at DatabaseWorkerTests.MyQueryRunnerTests.Execute_AgainstRealDb() in C:\GIT\reproIssuesOdbc-247\reproIssuesOdbc-247\MyQueryRunnerTests.cs:line 26

tomas.vladik Thank you for additional information and the testcase. I haven't run it yet, but looked in the code, and in connection string OPTION is 3, while for enable multiple statements it has to also contain the bit 67108864. Without that option set multiple statement should not work. Could you please add it and see if it still does not work? or I'll do this later.

Ok, with ;Option=67108864 it passes green.

But still it seems to me not correct to get AccessViolationException, when there is wrong combination of connection string and SQL query.

Does have any drawback to use flag Option=67108864 in connection string every time?
Even when most of times executed commands are single query?

tomas.vladik The driver returns SQL syntax error and points to the beginning of 2nd query as the place where the error is found. The error you see is rendered by .Net and I don't think we can have control over it.
As for drawbacks - I guess the main reason why people choose to forbid multistatement queries is security, as it makes impossible SQL injection. But I'd say it's pretty safe to turn it on. Especially with 3.1 driver as it uses only server side prepared statements.

I'm gonna close the ticket, as I think the reason for initial report is the same connection string option. My bad, that I never asked. Should be the first thing I had thought of. But somehow the first thing that crosses my mind, is always "bug in the connector" =)

Apparently the reason behind the initial report is not selected connection string option enabling multistatement queries. That had to be the first question I had asked, but somehow I did not