locked
OLEDB server access different between 32-bit and 64-bit ? RRS feed

  • Question

  • ok this one has got me baffled. We have an application written in vb.net that uses OLEDB to connect to SQL Server databases. In some cases we have clients with only small databases on various SQL Express flavours.

    The application has always been 32 bit but we're currently looking at changing it to 64-bit. But that's still a ways off.

    In the meantime we wrote a "launcher" application, targeting a 64-bit platform, that checks some prerequisites and then launches the main application.

    Now ...

    The application uses whatever OLEDB driver happens to be available on the user's machine. It checks in order or preference for a MSOLEDBSQL driver first, then various SQL Native Client drivers and finally the old OLEDBSQL one. This works fine on all our user PCs. The application reads the server from an .ini file and then creates the necessary connection string.

    Until we introduced this 64-bit Launcher.

    Now please hear me on this: we are absolutely, 100% confident that both the 64-bit "Launcher" and the 32-bit application read the same values from the same .ini file

    But this is where it gets weird.

    As we were upgrading some clients we found the Launcher wasn't working. The .ini file would contain a server name like MyLittleServer\SQLExpress and while the 32-bit application would connect to that just fine, the 64-bit application wouldn't. Then we would remove the \SQLExpress part from the server name so only MyLittleServer is left, and both of them work again.

    So no biggie, right? Until today when I found an example of one client where the 64-bit Launcher would only connect successfully when the server name in the ini file was MyLittleServer, but the 32-bit application would only connect successfully when the server name in the ini file was MyLittleServer\SQLExpress

    Oh drat. Now what? Thankfully I decided I'd try to find out the server's IP Address - 10.0.0.1 - and thankfully both the 32-bit and the 64-bit application connect perfectly happily when the server name in the ini file is set to 10.0.0.1

    but what gives? Can anybody explain to me why this is happening? Is there anything I can do to prevent it happening?


    Pino Carafa

    Wednesday, March 25, 2020 7:03 PM

All replies

  • Hi rozeboosje2,
    I viewed your description, it is recommended to report a problem on the Developer Community and you can get more professional answer.
    Thank you for your understanding.
    Best Regards,
    Daniel Zhang


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, March 26, 2020 9:16 AM
  • Thank you..... I will do - Indeed I wasn't sure where the best place would be to post this.

    Pino Carafa

    Thursday, March 26, 2020 10:21 AM
  • Why do you not simply use System.Data.SqlClient instead of OLEDB for connection to SQL Server???


    Please mark as answer, if this was it. Visit my SQL Server Compact blog http://erikej.blogspot.com

    Thursday, March 26, 2020 1:26 PM
  • "Why do you not simply use System.Data.SqlClient instead of OLEDB for connection to SQL Server???"

    *NOT* helpful. The application is years old, and now is not the time to change the entire underlying data access layer

    And besides, it doesn't answer the question.

    Even if we *could* set aside a couple of months to make this sweeping change and completely regression test our entire application, I would still like to know what causes *this* problem with an OLEDB connection. I'm curious like that.

    And to add to that: can you guarantee that System.Data.SqlClient won't suffer from the same problem? To me it seems that there is a problem in how the server name is resolved to an IP address. Who is to say that this problem originates in the data access driver? Unless I get an answer to this specific question I'm not going to take that sort of a leap into the unknown.


    Pino Carafa


    • Edited by rozeboosje2 Thursday, March 26, 2020 1:37 PM
    Thursday, March 26, 2020 1:29 PM

  • Pino Carafa

    Friday, May 1, 2020 1:11 PM
  • UPDATE

    I finally found out how to stop this from happening. If you start ODBCAD ("ODBC Data Sources 64-bit") you can go through the motions of configuring a new data source. The important bit is when you get to the second part of the Wizard where there is a Client Configuration button. If you uncheck the Dynamically determine port checkbox you can then enter the correct port (usually 1433) and proceed.

    After that it just works.

    Now I update my question. I assume this information is set in the registry somewhere. So my question now is:

    What values, where in the Registry, do I need to change so that I don't have to - and don't have to ask a user to - go through this UI?


    Pino Carafa

    Friday, May 1, 2020 1:11 PM