January 19, 2011 at 10:44 am
Hello!
I hope someone can help me with a general SQL Server 2008 R2 compatibility question but in order for it to make sense I need to deliver some background information.
I am an application developer with about 20 years experience in several pre .NET languages.
We wish to convert our Visual FoxPro 9.0 customized inventory system to .NET using Visual Studio 2008. At the same time we are cognizant of the 32 bit to 64 bit migration taking place everywhere and wish to be able to purchase and utilize a combination of hardware and software that will allow us to take the correct path from 32 bit to 64 bit over the next two years in two distinct steps.
Step 1
Our Step 1 goal is to be able to run a 32 bit .NET inventory application on Windows Server 2008 R2 64 bit operating system enabling the Windows 32 bit on Windows 64 bit (WoW64) subsystem (but not enabling the Server Core minimal footprint as we have lots of 64 bit server hardware horsepower).
On this Windows Server 2008 R2 64 bit platform we wish to install SQL Server 2008 R2 32 bit to allow ADO.NET connectivity to be able to achieve this goal.
Currently, our 15 or so workstations are about 50% 64 bit hardware architecture and 50% 32 bit hardware architecture. ALL workstation operating systems currently run Windows XP Professional 32 bit OS.
To complicate matters slightly we are also running AccPac 5.4 on a separate server and ideally we would like all users to be able to access BOTH the 32 bit .NET inventory application and AccPac 5.4 from their workstations. We realize that 64 bit AccPac is vapourware currently but is coming at some point in the future.
Step 2
Our Step 2 goal (in the next 1 to 2 years) is to convert all workstations to 64 bit hardware architecture AND run Windows 7 64 bit operating systems on all workstations. We wish to continue to run the Windows Server 2008 R2 64 bit operating system and we realize we will need to upgrade and migrate to SQL Server 2008 R2 64 bit at that time.
My question is this:
Given the configuration described above, can we successfully run a 32 bit [/b].NET inventory application on Windows Server 2008 R2 64 bit [/b]operating system enabling the Windows 32 bit on Windows 64 bit (WoW64) subsystem (but not enabling the Server Core minimal footprint) AND have ADO.NET successfully access SQL Server 2008 R2 32 bit [/b]???
In other words can we successfully achieve the Step 1 goal outlined above?
Thank you very much in advance for your help.
January 19, 2011 at 12:06 pm
To answer your question with a question: Why would you want to do this?
You can compile a .net application for 32 bit or 64 bit or both environments. The question is, is that if you are building new .net versions and want to run them against a 2008 server why would you not got directly to 64 bits? (Perhaps it is a cost issue, I am not really up on pricing differences between 32 and 64).
The probability of survival is inversely proportional to the angle of arrival.
January 19, 2011 at 12:23 pm
I would say to just ensure that the odbc drivers that you're going to use are available in both 32-bit and 64-bit flavors... then you shouldn't have to do anything differently.
Edit: the drivers for SQL 2008 R2 come in both 32 and 64 bit versions, and the OS will use the appropriate one. Install the 64-bit SQL on the server; the clients won't be able to tell the difference in connecting.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
January 19, 2011 at 1:10 pm
Perhaps I missed something..
I'm not sure why you want want to target an architecture unless you needed to.. The client drivers (native client) for 2005/2008/2008R2 all have 32 and 64-bit flavors. The driver flavor however has nothing to do with the server, what I mean is that a 32-bit driver has no issue talking to a 64-bit sql server or vice-versa. As a matter of fact unless you use extended stored procedures or targeted SQLCLR, your SQL code should not even be aware of 32 or 64 bit, and that is good..
Upon a re-reading of your post I can see a reason to target 32-bit for your CLIENT, at least for now. However keep in mind that you should still use 64-bit servers whenever possible.
CEWII
January 19, 2011 at 1:44 pm
Thank you for the information re: the ODBC drivers
January 19, 2011 at 2:09 pm
Hello Elliot:
Yes, it is the client that I am most concerned with but I wanted to provide a bit of background as to the versions of software we are intending to use in the future.
All of our client machines are Windows XP Pro 32 bit OS and need to remain so for many months even though we we have about a 50/50 mixture of 32 bit and 64 bit CPU's making up these client machines.
I assumed (perhaps incorrectly) that any .NET development that might take place needed to be compiled in 32 bit (x86) mode given that all workstations are 32 bit OS's and will remain so for a long time now.
I just wanted to confirm that future apps deployed on these 32 bit clients could successfully run on a 64 bit server box running Windows 2008 Server R2 64 bit and EITHER SQL Server 2008 R2 32 or 64 bit right now.
It brings up another question. If a .NET app is compiled in 64 bit mode (and we have BOTH Windows 2008 Server R2 64 bit and SQL Server 2008 R2 64 bit) on the server box, can the .Net app be deployed and run from the 32 bit XP client machines. I suspect not.
Initially, at least, I would be happy if I can compile the .NET apps in 32 bit mode AND successfully run them on Windows 2008 Server R2 64 bit and (SQL Server 2008 R2 32 OR 64 bit)
There is another consideration I did not mention before. AccPac 5.4 runs on its own server and is accessed by the 32 bit XP clients AND it is necessary for 1000's of Office 2007 (Word and Excel files mostly) to also reside on the 64 bit server box and be accessed from the 32 bit XP clients as well as any new .NET apps.
Would this be a problem or would it be necessary to upgrade to a true 64 bit OS (Windows 7 probably) on ALL client machines?
Thank you for your help.
January 19, 2011 at 2:28 pm
Mike,
I'm not sure you have to do anything when you compile the apps. They will be architecture agnostic unless you explicitly change the target architecture, so by default they will compile to MSIL.
Unless you use libraries that are ONLY for one architecture or another then you don't really have to specify.
Whether SQL is 32 or 64-bit is not important in any way to the client that connects to it.
You ask an interesting question about 64-bit OS', if the required drivers are not available in 64-bit flavors you can install them, however, your app will have to run as a 32-bit app. This is where I am unsure, I don't think that you can force an MSIL compiled app to run as a specific architecture, I *think* it follows the OS architecture.
I'm not sure if I answered everything..
CEWII
January 20, 2011 at 11:38 am
Hello Elliot,
Thank you for your input.
I have used SQL Server fairly extensively in the past but it was with very old versions (6.5 and 7.0)
We will be going with 64 bit for both Windows Server 2008 R2 and SQL Server 2008 R2.
I hope to be able to ask you some SQL Server specific questions as I continue to work with these new versions (probably some installation related questions)
Thank you and I look forward to talking to you in the future.
Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply