May 29, 2009 at 10:29 am
We have an odd error occurring with a given application whose database resides on one of our x64 SQL 2005 servers. The vendor immediately says their database is not x64 compatible and we must go back to x86. I told them this is hogwash, the database itself does not know anything about the bit version. SQL Server is 64 bit compatible and that is all that matters in this scenario. I even sent them doco from MS on how the disk, data, and page structure of the databases are exactly the same regardless of what "bit version' of the engine they are running on.
All I am hearing is if it works on 32 bit then we recommend you run on 32 bit. Never mind the dozens of other differences between the test and prod boxes.
BTW.... this is a basic client/server connection. Specific to the bit version, am I missing something? Me and every other post I have found online have this right, correct?
I freely move database between 32 and 64 bit all the time. x86 is not our production standard though.
May 29, 2009 at 11:11 am
There are some differences. For example, so far as I know, there isn't a JET driver for 64-bit SQL Server. At least, not built in. If, for example, the database requires that, and you haven't set one up, it will almost certainly generate errors. There are some other minor issues like that.
The database itself won't know the difference, but if there's a driver issue with a connection to a file external to the database, that might be an area to address.
What's the error you're getting?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
May 29, 2009 at 12:05 pm
There are many differences when it comes to application because if it is a .NET application developed with .NET 1.1 is cannot run x64 RDBMS without some issues could be minor or serious. I will comment about .NET because I was one of the top x64 helper on .NET, if the application can be compiled as AnyCPU that is both x86 and x64 then you can just move the database to x64. If you are getting problems these comes from dependent dll issues and if these dll don't qualify for AnyCPU then you may have to run your application with x86.
So most issues are related to dependent dll and I agree with you there is no reason to run x86 RDBMS in production, the Windows platform is the only place with a lot of x86 RDBMS in production.
Kind regards,
Gift Peddie
May 29, 2009 at 1:12 pm
This is a simply client app, conenction via ODBC. TSQL through the ODBC.
I can think of no issues there.
May 29, 2009 at 1:15 pm
BTW.... on occasion there is an ambiguous error, at other times the application simply dies on the local workstation. I have done Profiler traces and there is nothing out of the ordinary coming back from the SQL Server side. Even if there was, you would think that error handling within the app would throw out something and not just kill the app.
Regardless, the vendor simply cites 64bit and will not talk about it any more.
May 29, 2009 at 1:16 pm
Then you could just use the x64 ODBC driver to configure connection for the application, I am sure your vendor would not have issues with that. This could be a driver issue so you need to make sure your application can run with x64 ODBC or use the x86 ODBC driver in the WOW64 directory of x64 Win2003.
Kind regards,
Gift Peddie
May 29, 2009 at 1:20 pm
They have issues with the dedicated DB server being 64 bit. There is no DLL or .NET framework involved on the server. This is a client application talking TSQL through an ODBC to a SQL database. It should not matter at all what the bit version of the DB engine is.
Gift Peddie (5/29/2009)
There are many differences when it comes to application because if it is a .NET application developed with .NET 1.1 is cannot run x64 RDBMS without some issues could be minor or serious. I will comment about .NET because I was one of the top x64 helper on .NET, if the application can be compiled as AnyCPU that is both x86 and x64 then you can just move the database to x64. If you are getting problems these comes from dependent dll issues and if these dll don't qualify for AnyCPU then you may have to run your application with x86.So most issues are related to dependent dll and I agree with you there is no reason to run x86 RDBMS in production, the Windows platform is the only place with a lot of x86 RDBMS in production.
May 29, 2009 at 1:25 pm
Just to clarify, the connection is coming from client machines running on Windows XP 32 bit. The connection should be seamless through ODBC. You cannot use an x64 drive on an 32 bit OS.
Gift Peddie (5/29/2009)
Then you could just use the x64 ODBC driver to configure connection for the application, I am sure your vendor would not have issues with that. This could be a driver issue so you need to make sure your application can run with x64 ODBC or use the x86 ODBC driver in the WOW64 directory of x64 Win2003.
May 29, 2009 at 1:28 pm
Actually it matters that is the reason the x64 boxes installs both x86 and x64 drivers so you can use the correct driver as needed. Office is not a .NET application but because it uses x86 OLEDB driver you must run anything using Office as x86 in x64 boxes SQL Server included.
Just to clarify, the connection is coming from client machines running on Windows XP 32 bit. The connection should be seamless through ODBC. You cannot use an x64 drive on an 32 bit OS.
That is the reason there is both x86 and x64 drivers in the x64 boxes I have been doing this since 2001 I used Win2003 in alpha build.
Kind regards,
Gift Peddie
May 29, 2009 at 1:32 pm
Maybe I am just getting confused. But yes, an x64 OS installs both the x86 and x64 drivers so clients can connect via either. My point is, there is no valid reason that a client, sitting on Windows XP 32-bit cannot communicate flawlessly (good ole TSQL via ODBC) with a SQL Server 2005 64bit instance, residing of course on an x64 OS.
Gift Peddie (5/29/2009)
Actually it matters that is the reason the x64 boxes installs both x86 and x64 drivers so you can use the correct driver as needed. Office is not a .NET application but because it uses x86 OLEDB driver you must run anything using Office as x86 in x64 boxes SQL Server included.
May 29, 2009 at 1:40 pm
Maybe I am just getting confused. But yes, an x64 OS installs both the x86 and x64 drivers so clients can connect via either. My point is, there is no valid reason that a client, sitting on Windows XP 32-bit cannot communicate flawlessly (good ole TSQL via ODBC) with a SQL Server 2005 64bit instance, residing of course on an x64 OS.
I do both layers and I am telling you if your vendor says you cannot use x64 ODBC you need to create an x86 ODBC connection that the x86 users can use because currently the x86 XP is trying to keep a connection that is not stable. The x86 ODBC is in the WOW64 directory I almost forgot you must be in SP2 to get it. If you are not in SP2 that could be your problem.
Kind regards,
Gift Peddie
May 29, 2009 at 2:19 pm
Just to clarify.
1. The vendor has simply stated that their DB is not "64-bit compliant".
2. The client machines are 32bit so the only option is the x86 odbc. These ODBCs are on the client PCs, nothing needed on the server.
3. "x86 XP is trying to keep a connection that is not stable" -- this statement is based on??
Gift Peddie (5/29/2009)
Maybe I am just getting confused. But yes, an x64 OS installs both the x86 and x64 drivers so clients can connect via either. My point is, there is no valid reason that a client, sitting on Windows XP 32-bit cannot communicate flawlessly (good ole TSQL via ODBC) with a SQL Server 2005 64bit instance, residing of course on an x64 OS.
I do both layers and I am telling you if your vendor says you cannot use x64 ODBC you need to create an x86 ODBC connection that the x86 users can use because currently the x86 XP is trying to keep a connection that is not stable. The x86 ODBC is in the WOW64 directory I almost forgot you must be in SP2 to get it. If you are not in SP2 that could be your problem.
May 29, 2009 at 2:33 pm
.... on occasion there is an ambiguous error, at other times the application simply dies on the local workstation
The above is the reason for my statement and a client application connection starts with the server so if your users are connecting to your x86 driver you will not get any problems, all Office application connections to x64 operating systems are fixed by using the x86 ODBC in WOW64 directory of Win2003 SP2. And you must know one database using x86 ODBC will not affect your application. I have found most migration to x64 using x86 in x64 works without issues and help companies deplay code rewrite.
Kind regards,
Gift Peddie
May 29, 2009 at 4:36 pm
Gift Peddie (5/29/2009)
.... on occasion there is an ambiguous error, at other times the application simply dies on the local workstation
The above is the reason for my statement and a client application connection starts with the server so if your users are connecting to your x86 driver you will not get any problems, all Office application connections to x64 operating systems are fixed by using the x86 ODBC in WOW64 directory of Win2003 SP2. And you must know one database using x86 ODBC will not affect your application. I have found most migration to x64 using x86 in x64 works without issues and help companies deplay code rewrite.
Gift, I have to agree with SQLDBA here. I see nothing that says a database hosted on a x64 server requires the client running on an x86 machine to know anything about whether or not the host is running x64.
I don't get it - please provide any and all links to documents that show that a client coming from an x86 machine needs to know anything about the database server other than the server name and port to connect to. ODBC/OLEDB does not care one way or the other what the server is running. ODBC/OLEDB drivers open a connection to the database, submit queries and retrieve the results.
Thanks.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
May 29, 2009 at 4:56 pm
Gift, I have to agree with SQLDBA here. I see nothing that says a database hosted on a x64 server requires the client running on an x86 machine to know anything about whether or not the host is running x64.
I developed against x64 Oracle my code must build AnyCPU because it was both x64 and x86, if I build my code x64 I get BadImageFormatException. It takes about one minute to resolve in development build either AnyCPU or x86, without code connect through x86 ODBC in WOW64 directory.
http://msdn.microsoft.com/en-us/library/system.badimageformatexception.aspx
ODBC/OLEDB does not care one way or the other what the server is running. ODBC/OLEDB drivers open a connection to the database, submit queries and retrieve the results.
If that is correct Office application can run against SQL Server x64 without using ODBC x86 in the WOW64 directory Microsoft had to add it with SP2 in Win2003 because developers cannot use Access or Excel with Win2003.
Kind regards,
Gift Peddie
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply