When using a ODBC v2 driver, the function SQLSetEnvAttr might not be available.
From: Alistair Leslie-Hughes leslie_alistair@hotmail.com
--- dlls/odbc32/proxyodbc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/dlls/odbc32/proxyodbc.c b/dlls/odbc32/proxyodbc.c index 2a62fd88d64..4f23c761f5a 100644 --- a/dlls/odbc32/proxyodbc.c +++ b/dlls/odbc32/proxyodbc.c @@ -1162,7 +1162,7 @@ static int has_suffix( const WCHAR *str, const WCHAR *suffix )
static SQLRETURN set_env_attr( struct environment *env, SQLINTEGER attr, SQLPOINTER value, SQLINTEGER len ) { - SQLRETURN ret = SQL_ERROR; + SQLRETURN ret = SQL_SUCCESS;
if (env->hdr.unix_handle) { @@ -1171,7 +1171,8 @@ static SQLRETURN set_env_attr( struct environment *env, SQLINTEGER attr, SQLPOIN } else if (env->hdr.win32_handle) { - ret = env->hdr.win32_funcs->SQLSetEnvAttr( env->hdr.win32_handle, attr, value, len ); + if (env->hdr.win32_funcs->SQLSetEnvAttr) + ret = env->hdr.win32_funcs->SQLSetEnvAttr( env->hdr.win32_handle, attr, value, len ); }
return ret;
Is there a real world use case for this? There are more functions missing from v2 drivers and they can't all be emulated. So the app would need to be aware of that. In any case, I think the reverse mapping of dropped v2 functions has higher priority.
On Tue Aug 13 07:47:36 2024 +0000, Hans Leidekker wrote:
Is there a real world use case for this? There are more functions missing from v2 drivers and they can't all be emulated. So the app would need to be aware of that. In any case, I think the reverse mapping of dropped v2 functions has higher priority.
Yes in the real world. The driver I was helping someone with doesn't have this function.
Why would an application need to know? I write an application with ODBC v3.0 functions and connect via DSN with a driver v2.0. I expect ODBC32 to handle as much as possible. From experience you sometime have to set specific driver options but that was an unusual case.
wine is explicitly setting SQL_ATTR_ODBC_VERSION on creating the environment handle, with a function that might not exist.
On Tue Aug 13 07:47:36 2024 +0000, Alistair Leslie-Hughes wrote:
Yes in the real world. The driver I was helping someone with doesn't have this function. Why would an application need to know? I write an application with ODBC v3.0 functions and connect via DSN with a driver v2.0. I expect ODBC32 to handle as much as possible. From experience you sometime have to set specific driver options but that was an unusual case. wine is explicitly setting SQL_ATTR_ODBC_VERSION on creating the environment handle, with a function that might not exist.
By real world I mean a real v3 application that needs to work with a v2 driver.
On Tue Aug 13 07:56:40 2024 +0000, Hans Leidekker wrote:
By real world I mean a real v3 application that needs to work with a v2 driver.
I believe the application was written in .NET of some sort, so yes.
On Tue Aug 13 08:17:29 2024 +0000, Alistair Leslie-Hughes wrote:
I believe the application was written in .NET of some sort, so yes.
Is there a free download for this app?
On Tue Aug 13 08:30:32 2024 +0000, Hans Leidekker wrote:
Is there a free download for this app?
No, I only had the driver.
On Tue Aug 13 08:32:07 2024 +0000, Alistair Leslie-Hughes wrote:
No, I only had the driver.
Would it be particularly hard to write unit tests for this? We have decent support for test DLLs now, and unless Windows does an awful lot of validation on driver capabilities or exports it doesn't seem hard to write a minimal amount of code?
And if Windows does do a lot of validation, would it be particularly hard to just write an out-of-tree test with an existing v2 driver?
On Thu Aug 15 17:46:47 2024 +0000, Elizabeth Figura wrote:
Would it be particularly hard to write unit tests for this? We have decent support for test DLLs now, and unless Windows does an awful lot of validation on driver capabilities or exports it doesn't seem hard to write a minimal amount of code? And if Windows does do a lot of validation, would it be particularly hard to just write an out-of-tree test with an existing v2 driver?
I briefly looked at an ODBC Amazon v2 driver but unfortunately the database is behind a paid service. v2 drivers seem to be rare these days. We could write a v2 test driver but I'm not sure if it's worth the effort. Question is also what to focus on without a specific app.
There is an ODBC v2 driver for Microsoft Jet database on windows. (32 bit driver only) - A standard windows one. Having a look at it's exports, doesn't have SQLSetEnvAttr.
Regardless if we have an application, the above driver cannot be used since wine is using a function that is ODBC v3.0 only. The talk about adding support for fallback v2.0 functions is pointless if calling SQLConnection causes a crash.
As a note. The user with the issue, is using a .NET application to interface with an legacy database which only has a v2.0 driver available.
Sure SQLSetEnvAttr() is missing but it's far from the only function. Before that it was SQLAllocHandle() and I'm sure there will be more after SQLSetEnvAttr(). Backwards compatibility is a big task for a small gain, given how many v2 drivers are around today. The general point is that this should be driven by the needs of real applications. Could you ask this user to get a +odbc trace from current wine-staging? I'll see if I can make that Jet driver work.
-
Alistair Leslie-Hughes -
Alistair Leslie-Hughes (＠alesliehughes)
-
Elizabeth Figura (＠zfigura)
-
Hans Leidekker (＠hans)