SQL Server (SQLSRV32.DLL) on Windows Vista SP2
Hex: 0x08,0x00,0x01,0x55
Parsed: 08.00.341
Product Version (on the dll): 6.0.6002.18005
Product Version (on the dll): 6.0.6002.18005
Hex: 0x09,0x00,0x0b,0xe2
Parsed: 09.00.3042
Product Version (on the dll): 9.0.3042.0
Product Version (on the dll): 9.0.3042.0
SQL Native Client 10 (SQLNCLI10.DLL) for SQL Server 2008 R2 SP3
Hex: 0x00,0x2e,0x00,0x00
Parsed: 00.46.0000
Product Version (on the dll): 10.50.6000.34
Product Version (on the dll): 10.50.6000.34
SQL Native Client 11 (SQLNCLI11.DLL) for SQL Server 2012 SP1
Hex: 0x0b,0x00,0x0b,0xb8
Parsed: 11.00.3000
Product Version (on the dll): 11.0.3000.0
Product Version (on the dll): 11.0.3000.0
Hex: 0x0b,0x00,0x08,0xde
Parsed: 11.00.2270
Product Version (on the dll): 11.0.2270.0
Product Version (on the dll): 11.0.2270.0
For the most part, the version numbers match up with the "Product Version" on the dll, except the built-in SQL Server driver and SQL Native Client 10.
The built-in SQL Server driver is a holdover from the old days of MDAC, where you had to manually install drivers onto Windows to get connected. Starting with Windows Vista, the built-in SQL Server driver truly became built into the OS. From that point forward, the Product Version on the dll would always match the OS.
With the SQL Native Client 10, I have no idea what's going on there. Considering the version number sent by SQL Native Client 10, I can only assume that the SQL Server ignores the version number being sent and that other features determine compatibility. Perhaps compatibility is left strictly to the client. On the client side, I'm guessing that drivers make a number of assumptions based on the server version being sent back as well as various function calls, like the ODBC SQLGetTypeInfo, SQLGetFunctions, and SQLGetInfo functions.
I think I've been nerd sniped again.
The built-in SQL Server driver is a holdover from the old days of MDAC, where you had to manually install drivers onto Windows to get connected. Starting with Windows Vista, the built-in SQL Server driver truly became built into the OS. From that point forward, the Product Version on the dll would always match the OS.
With the SQL Native Client 10, I have no idea what's going on there. Considering the version number sent by SQL Native Client 10, I can only assume that the SQL Server ignores the version number being sent and that other features determine compatibility. Perhaps compatibility is left strictly to the client. On the client side, I'm guessing that drivers make a number of assumptions based on the server version being sent back as well as various function calls, like the ODBC SQLGetTypeInfo, SQLGetFunctions, and SQLGetInfo functions.
I think I've been nerd sniped again.
hadoop training
ReplyDeleteData Science training
linux training
mulesoft training
web methods training
business analyst online training
oracle adf online training