Re: [INTERNALS-WIN] Re: ext/odbc no longer builds under VC6

Hi Patrick,

>> move to this API? What about Windows 2000 Server, where do we stand  with 
>> support for that these days?
>>
>> (NB we only dropped support for Windows 98 two years ago.)
>>
>
> No, the 32bit ODBC specification is backward compatible all the way  back 
> to Windows NT  which came before Windows 2000.

Ah, cool, thanks.

> In the ODBC API specification, there are certain fields that needed 
> either a pointer or an integer value or a length of a blob. Since 
> Microsoft 64 bit OS has both integer and long defined as 32 bit 
> quantities, they added a new typedef called SQLLEN which is a 64bit 
> quantity on 64 bit Windows, but a normal 32 bit quantity on 32 bit 
> windows.

Yes, I saw that - I was just concerned that the client libraries wouldn't 
know what an SQLLEN was.

> So these changes have nothing to do with dropping support for earlier 
> versions of Windows.

Good, and thank you for the clarification.

> The compiler package would probably also have installed a version of  the 
> Platform SDK, but these have always been separately maintained  and 
> downloadable through the Microsoft download site. In the past you  did not 
> need a genuine windows certificate in order to download any  of these.
>
> Did you check if there was any SP1 package for your version of the 
> compiler?

I'm on SP6 for MSVC6. But the link I gave earlier 
(http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en) 
contains the correct libs and headers. The installer puts them into 
C:\Program Files\Microsoft Platform SDK rather than touching the VC6 
installation.

> These types never existed in ODBC 2.5 and 3.0 and my official  Microsoft 
> 3.0 Programmers reference books has no mention of them.

No... I'm bewildered as to how I ended up with an sqltypes.h claiming to be 
ODBC 3.51 but lacking a SQLLEN definition. The date on that file is 1998.

> I believe the problem is that Microsoft put these defines into ODBC  3.51 
> release and have some official Microsoft headers from around  2000 which 
> already have the SQLLEN inside sqltypes.h. At some point  they added some 
> other new typedefs, but these where removed when they  officially synced 
> the API with the SAG group.

Yes, there were some weird ones I came across in the docs on my travels... 
that would explain them :)

> It could be they first started with an internal 3.50 version and  moved to 
> 3.51 when they synced with SAG, but i have no definite proof  of this. By 
> this time Microsoft already tried to steer everyone away  from ODBC and 
> tried to windows programmers to OLEDB to keep them  locked to the windows 
> platform. My company and others had already  successfully ported the ODBC 
> specification to non windows platforms.

Sweet :)

> In any case, since they did not change anything for 32bit ODBC use,  they 
> might have thought they did not really need to change the  ODBCVER setting 
> to reflect a major change in the API.

Bizarre, but possible.

> I cannot explain why you got header files that use ODBCVER 0x0351 but 
> have no mention of SQLLEN and SQLULEN. You may need to ask Microsoft 
> about this. I would also make sure there is no update for your compiler.

None that contain this, no.

>> #ifndef SQLLEN
>> #define SQLLEN SQLINTEGER
>> #define SQLULEN SQLUINTEGER
>> #endif
>>
>
> That is all that should be needed on 32bit, but if you where to try  and 
> use these settings with the 64bit compiler, you would get some  serious 
> crashes, so i need to check

I wouldn't put that in a x-platform file :) Consider it proof-of-concept.

>> It's not clear to me which MDAC package I should be downloading to  get 
>> SQLLEN defined in the headers/libs. Do you know which you're  using?
>
> As far as i know was using MDAC 2.8 SP1 on my previous development  box, 
> but i will check to make sure.

It came in with MDAC 2.7 but you can't get that now, so it must be MDAC 2.8 
(and you'd presumably need the service patch if you had that anyway.) Or... 
just the sweet SDK link I found.

Hopefully we've covered this enough on-list now to be helpful for anyone 
else with the same issue.

Thank you for all your help,

- Steph