SQL_ATTR_ANSI_APP not set on Unicode driver that also supports ANSI API

[efternavn]

I am trying to use the unixODBC DM with the MariaDB ODCB driver (3.1.11) which supports both the ANSI and the Unicode API. My application uses the ANSI API.

If I understand Microsoft's description of the attribute SQL_ATTR_ANSI_APP here and in sqlext.h, the unixODBC DM should detect the MariaDB driver as a Unicode driver and try to set SQL_ATTR_ANSI_APP to SQL_AA_TRUE in my scenario. But in SQLConnect.c:4018, the SQL_ATTR_ANSI_APP code is out-commented (and code should probably also be conditioned by CHECK_SQLCONNECTW( connection )) which causes the MariaDB driver to run in a non-ANSI mode.

I can use DMConnAttr = [115]=\1 to work around the problem, but my understanding is that the attribute should be handled by the DM alone (and that option is also not available in the RHEL/CentOS 7 version of unixODBC). I realize that unixODBC DM in my scenario uses the ANSI API on the driver (as opposed to Microsoft's DM, right?) which perhaps explains why the handling of the attribute is out-commented -- leaving me try to reach out to the MariaDB developers instead.

Finally, I'm afraid I don't have a small example application that shows the problem. I could perhaps write one, if you need it. In my application, problem is starting to show after this MariaDB bug was fixed in the 3.1 series of their ODBC driver as they now respect the ANSI attribute in more cases.

[v-chojas]

The primary difference between ANSI and Unicode drivers is that their APIs have different string widths, but otherwise everything else should be the same. What is the exact problem your application is experiencing? Providing an ODBC trace may help.

[lurcher]

On 25/03/2021 13:29, efternavn wrote:

I am trying to use the unixODBC DM with the MariaDB ODCB driver (3.1.11) which supports both the ANSI and the Unicode API. My application uses the ANSI API.

If I understand Microsoft's description of the attribute SQL_ATTR_ANSI_APP here https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/unicode-drivers and in sqlext.h https://github.com/microsoft/ODBC-Specification/blob/b7ef71fba508ed010cd979428efae3091b732d75/Windows/inc/sqlext.h#L141, the unixODBC DM should detect the MariaDB driver as a Unicode driver and try to set SQL_ATTR_ANSI_APP to SQL_AA_TRUE in my scenario. But in SQLConnect.c:4018 https://github.com/lurcher/unixODBC/blob/d0ba899d25735504a45fe9282237e0434111ea4f/DriverManager/SQLConnect.c#L4018, the SQL_ATTR_ANSI_APP code is out-commented (and code should probably also be conditioned by |CHECK_SQLCONNECTW( connection )|) which causes the MariaDB driver to run in a non-ANSI mode https://github.com/mariadb-corporation/mariadb-connector-odbc/blob/1316c794725c8078f3a1ad9867960b9228b20df6/ma_connection.c#L158.

I can use |DMConnAttr = [115]=\1| to work around the problem, but my understanding is that the attribute should be handled by the DM alone (and that option is also not available in the RHEL/CentOS 7 version of unixODBC). I realize that unixODBC DM in my scenario uses the ANSI API on the driver (as opposed to Microsoft's DM, right?) which perhaps explains why the handling of the attribute is out-commented -- leaving me try to reach out to the MariaDB developers instead.

Finally, I'm afraid I don't have a small example application that shows the problem. I could perhaps write one, if you need it. In my application, problem is starting to show after this MariaDB bug https://jira.mariadb.org/browse/ODBC-185 was fixed in the 3.1 series of their ODBC driver as they now respect the ANSI attribute in more cases.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/68, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62INCTDVBCPRER7TEXDTFM3E3ANCNFSM4ZZLOPBQ.

I am trying to track down when that was commented out and why. From what I can see it was already commented out when we moved to subversion 2009-12-11. But I can't at the moment see why its absence would cause any driver to fail. My question would be the one asked, what is the problem this causes?

Its only a guess, but I would suspect it was commented out because its existence caused a driver a problem but I can't say what and which one at the moment.

--

Nick

[lurcher]

On 25/03/2021 14:46, v-chojas wrote:

The primary difference between ANSI and Unicode drivers is that their APIs have different string widths, but otherwise everything else should be the same. What is the exact problem your application is experiencing? Providing an ODBC trace may help.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/68#issuecomment-806881273, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62O3R33KXR6WTKXSYFLTFNEE7ANCNFSM4ZZLOPBQ.

Given the lack of description about it being commented out, I am prepared to believe I may have checked it in with it like that by mistake 11 or more years ago.

[efternavn]

The primary difference between ANSI and Unicode drivers is that their APIs have different string widths, but otherwise everything else should be the same. What is the exact problem your application is experiencing? Providing an ODBC trace may help.

Thanks for looking into this already! The problem is that when my application uses SQLColumns, it for instance gets SQL_WVARCHAR datatypes for varchar columns where it had expected to get SQL_VARCHAR. This behaviour is caused by a use of the ANSI attribute in the MariaDB driver -- whether that's a valid use of the attribute, I'm afraid I can't judge.

[efternavn]

On 25/03/2021 14:46, v-chojas wrote: The primary difference between ANSI and Unicode drivers is that their APIs have different string widths, but otherwise everything else should be the same. What is the exact problem your application is experiencing? Providing an ODBC trace may help. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62O3R33KXR6WTKXSYFLTFNEE7ANCNFSM4ZZLOPBQ. Given the lack of description about it being commented out, I am prepared to believe I may have checked it in with it like that by mistake 11 or more years ago.

Sounds plausible.

But don't you agree that before enabling the code, it should be conditioned by CHECK_SQLCONNECTW( connection )?

[lurcher]

On 25/03/2021 15:39, efternavn wrote:

On 25/03/2021 14:46, v-chojas wrote: The primary difference
between ANSI and Unicode drivers is that their APIs have different
string widths, but otherwise everything else should be the same.
What is the exact problem your application is experiencing?
Providing an ODBC trace may help. — You are receiving this because
you are subscribed to this thread. Reply to this email directly,
view it on GitHub <#68 (comment)
<https://github.com/lurcher/unixODBC/issues/68#issuecomment-806881273>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYK62O3R33KXR6WTKXSYFLTFNEE7ANCNFSM4ZZLOPBQ.
Given the lack of description about it being commented out, I am
prepared to believe I may have checked it in with it like that by
mistake 11 or more years ago.

Sounds plausible.

But don't you agree that before enabling the code, it should be conditioned by |CHECK_SQLCONNECTW( connection )|?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/68#issuecomment-806968677, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62OQ4QB73TD47XWEKYLTFNKM3ANCNFSM4ZZLOPBQ.

From what I can see the commented out call was added in between 2.2.1 and 2.2.2 from between Apr 23, 2002 and Jul  8,  2002. It was never released it seems with the commented out version.

I can see that it should be added back in, and them we may find why it was removed, but I don't see any reason to use the |CHECK_SQLCONNECTW status as its a measure of the application and its behavior not the driver.|

[v-chojas]

The problem is that when my application uses SQLColumns, it for instance gets SQL_WVARCHAR datatypes for varchar columns where it had expected to get SQL_VARCHAR.

Could you elaborate on this? Do you mean the metadata resultset that SQLColumns fetches contains wide column names, or that it misreports the datatype of the columns of the table you're retrieving the metadata for?

[efternavn]

The problem is that when my application uses SQLColumns, it for instance gets SQL_WVARCHAR datatypes for varchar columns where it had expected to get SQL_VARCHAR.

Could you elaborate on this? Do you mean the metadata resultset that SQLColumns fetches contains wide column names, or that it misreports the datatype of the columns of the table you're retrieving the metadata for?

Yes, sorry for being too brief. It's the latter, the datatype of the varchar columns is misreported.

[efternavn]

On 25/03/2021 15:39, efternavn wrote: On 25/03/2021 14:46, v-chojas wrote: The primary difference between ANSI and Unicode drivers is that their APIs have different string widths, but otherwise everything else should be the same. What is the exact problem your application is experiencing? Providing an ODBC trace may help. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#68 (comment) <#68 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62O3R33KXR6WTKXSYFLTFNEE7ANCNFSM4ZZLOPBQ. Given the lack of description about it being commented out, I am prepared to believe I may have checked it in with it like that by mistake 11 or more years ago. Sounds plausible. But don't you agree that before enabling the code, it should be conditioned by |CHECK_SQLCONNECTW( connection )|? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62OQ4QB73TD47XWEKYLTFNKM3ANCNFSM4ZZLOPBQ. From what I can see the commented out call was added in between 2.2.1 and 2.2.2 from between Apr 23, 2002 and Jul 8, 2002. It was never released it seems with the commented out version. I can see that it should be added back in, and them we may find why it was removed, but I don't see any reason to use the |CHECK_SQLCONNECTW status as its a measure of the application and its behavior not the driver.|

Okay. I don't have a strong opinion on that. I suggested that the ANSI attribute was only set if the driver supplied the Unicode API as I thought that would be closer to the way Microsoft describes the attribute. And if there's no Unicode API, I can't see the use of setting the attribute. Finally, I guess that enabling the out-commented code would affect fewer drivers if it only applied to the ones that supplied both APIs.

[lurcher]

On 25/03/2021 16:41, efternavn wrote:

On 25/03/2021 15:39, efternavn wrote: On 25/03/2021 14:46,
v-chojas wrote: The primary difference between ANSI and Unicode
drivers is that their APIs have different string widths, but
otherwise everything else should be the same. What is the exact
problem your application is experiencing? Providing an ODBC trace
may help. — You are receiving this because you are subscribed to
this thread. Reply to this email directly, view it on GitHub <#68
<https://github.com/lurcher/unixODBC/issues/68> (comment) <#68
(comment)
<https://github.com/lurcher/unixODBC/issues/68#issuecomment-806881273>>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYK62O3R33KXR6WTKXSYFLTFNEE7ANCNFSM4ZZLOPBQ.
Given the lack of description about it being commented out, I am
prepared to believe I may have checked it in with it like that by
mistake 11 or more years ago. Sounds plausible. But don't you
agree that before enabling the code, it should be conditioned by
|CHECK_SQLCONNECTW( connection )|? — You are receiving this
because you commented. Reply to this email directly, view it on
GitHub <#68 (comment)
<https://github.com/lurcher/unixODBC/issues/68#issuecomment-806968677>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYK62OQ4QB73TD47XWEKYLTFNKM3ANCNFSM4ZZLOPBQ.
From what I can see the commented out call was added in between
2.2.1 and 2.2.2 from between Apr 23, 2002 and Jul 8, 2002. It was
never released it seems with the commented out version. I can see
that it should be added back in, and them we may find why it was
removed, but I don't see any reason to use the |CHECK_SQLCONNECTW
status as its a measure of the application and its behavior not
the driver.|

Okay. I don't have a strong opinion on that. I suggested that the ANSI attribute was only set if the driver supplied the Unicode API as I thought that would be closer to the way Microsoft describes the attribute. And if there's no Unicode API, I can't see the use of setting the attribute. Finally, I guess that enabling the out-commented code would affect fewer drivers if it only applied to the ones that supplied both APIs.

Well, I think the problem is conflating the UNICODE API's with the Wide data types. A driver that only supports the ANSI API can return wide data types, so I don't think checking the API would be a valid thing to do in that case.

[kadler]

From the Microsoft doc linked, it doesn't say that the DM calls the driver with SQL_ATTR_ANSI_APP only if the driver is a UNICODE driver. It mentions that a driver may react differently based on whether the application is ANSI or UNICODE, but AFAICT an ANSI driver could behave differently to UNICODE applications just the same as a UNICODE driver could behave differently to ANSI applications (or any other combination).

[efternavn]

Well, I think the problem is conflating the UNICODE API's with the Wide data types. A driver that only supports the ANSI API can return wide data types, so I don't think checking the API would be a valid thing to do in that case.

Okay, that sounds reasonable.

[efternavn]

From the Microsoft doc linked, it doesn't say that the DM calls the driver with SQL_ATTR_ANSI_APP only if the driver is a UNICODE driver. It mentions that a driver may react differently based on whether the application is ANSI or UNICODE, but AFAICT an ANSI driver could behave differently to UNICODE applications just the same as a UNICODE driver could behave differently to ANSI applications (or any other combination).

Okay, I've probably misread the linked doc. Maybe it's because I only read the comment in the include file first.

[lurcher]

On 26/03/2021 06:20, efternavn wrote:

From the Microsoft doc linked, it doesn't say that the DM calls
the driver with SQL_ATTR_ANSI_APP /only/ if the driver is a
UNICODE driver. It mentions that a driver may react differently
based on whether the application is ANSI or UNICODE, but AFAICT an
ANSI driver could behave differently to UNICODE applications just
the same as a UNICODE driver could behave differently to ANSI
applications (or any other combination).

Okay, I've probably misread the linked doc. Maybe it's because I only read the comment in the include file first.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lurcher/unixODBC/issues/68#issuecomment-807969069, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYK62LGP3SQIL43C4NKS3TTFQRTZANCNFSM4ZZLOPBQ.

Unless there are any objections I will uncomment the code and we will see what happens in the next release. If it does cause a driver a problem, we are probably in a better position to suggest the driver change than I was 15 years ago :-)