5.10.49-gentoo-r1

It is frustrating when a clearly comprehensible error is not processed for months.
The question inevitably arises as to why errors should be reported at all if nothing happens anyway.

In my case, I use a self-patched version, which fixes the bug.
But I always have to handle the case specifically with every available update.

Sorry for not reacting. Your report is in fact a duplicate.

Please see ODBC-298, ODBC-297
This was our interpretation of specifications. And if you read here https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/arguments-in-catalog-functions you will see, that SQLTables arguments are pattern values, and if you follow the link for pattern values description https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/pattern-value-arguments, you can read there "Passing a null pointer to a search pattern argument does not constrain the search for that argument; that is, a null pointer and the search pattern % (any characters) are equivalent." , that kinda suggests, that our interpretation is correct. But since MS itself read it differently, we will change this. But not in the scope of current GA series.

I can understand your frustration, but if you searched thru the jira tickets prior to report the issue, you could avoid this frustration in this particular case.

Now I will close it as a duplicate. Sorry once again, I should have done that much earlier

Thank for the Answer.

If i filter the Catalogname
Rc=SQLTables(hstmt, // Get all Tablenames for the current DB
(SQLCHAR*)DataBase,SQL_NTS, // CatalogName, Length
NULL,0, // SchemaName, Length
NULL,0, // TableName,Length
(SQLCHAR*)"TABLE",SQL_NTS); // TableType, Length

i get the correct Result using mariadb-connector-odbc-3.1.13

There must be incomaptibilty between the current V3.13 and V3.1.6.
With V3.1.6 i get the correct Result without filtering the CatalogName.

Hmm.... the change(treating NULL as "any") was introduced with ODBC-245 in 3.1.1, which was first ga release of 3.1.
You are saying, that 3.1.6 worked the old way? i.e. there was regression somewhere between 3.1.1 and 3.1.6?
I need to look for this. Can't see it yet. Besides, there was the testcase introduced with ODBC-245 fix and I can't see that test was ever changed since then.

I think you are right.
The first time i had the Problem is long time a go.
After that i patched the Releases and i think the last Version i patched was 3.1.6.

After that the patching was to complicated.
This last patched Version was then frozen on my Server.

You've started me thinking. Since this behavior is changed back and forth from version to version, it's probably better to make it optional, and leave current behavior default in current(3.1) series, and new/old one to be default in the next(3.2) series. I'll continue in ODBC-298

It would be helpful if the behavior of SQLTables didn't change from version to version.

I have adapted my own Rexx interpreter so that the catalog name parameter is never NULL in the SQLTables call.

Rc=SQLTables(hstmt, // Get all table names
(SQLCHAR*)DataBase,SQL_NTS, // CatalogName, Length
NULL,0, // SchemaName, Length
NULL,0, // TableName,Length
(SQLCHAR*)"TABLE",SQL_NTS); // TableType, Length

I hope that this change will continue to deliver the right result in the future.

Yeah, (frequent)changing is not a good thing, but seems like most people expect MS behavior, i.e. NULL means current. Making the behavior optional is good solution is such case.

I totally agree with you hat API calls shouldn't return different results with each new version.

M$ has always struggled with specs. This has been known for years.
A good example of what NOT to do.

I work on Linux and API's are rock solid normally.

Maybe it's possible to add a test to see if odbc has opened a MsAccess DB.
Accordingly, other defaults apply for such DB's.
Just an idea.