I'm about to install SQL Server 2012 Developer on my 64-bit machine for developing purposes, but I'm not sure if I should install the 32-bit or 64-bit version.
My confusion comes from the fact that my Visual Studio 2012 is 32-bit and my laptop is not quite fast (Intel Core2Duo P8400 # 2.26Ghz with 5GB RAM).
Generally speaking 64-bit or 32-bit app installation on 64-bit machine is the right choice?
The default solution to all SQL Server performance problems is to throw more memory at it. That only works above 4GB if you have 64 bit SQL Server on a 64 bit machine. You already have a 64 bit machine with more than 4GB memory therefore installing the 64 bit version of SQL Server is a no brainer.
Note that it doesn't matter if you don't have to support a very large database at the time you have to make the decision because you don't know what the future will bring. I have had exactly that experience and am now really glad that at the time I installed the 64 bit version and now am working with a 50+GB database. Something I didn't anticipate at the time.
There is no general advice which version to install. Visual Studio runs in a 32bit process, but your project can target 64bit because it will be debugged within another process.
The main question is: How much RAM do you think your database will need? There aren't any drawbacks on installing 64bit software on 64bit machines, but 32bit software will be executed on a compatibility layer (WoW64 - windows on windows 64).
Using 32 or 64 bit software on old hardware makes no difference, either. As long as the processor supports it!
There is no such a thing as Visual Studio 64bit, VS only comes 32bit regardless the operating system and the project target, this is due to the fact that VS UI will execute different processes external tasks
As for SQL Microsoft instructions strongly recommend to install SQL 32bit versions only when running on a 32bit OS version.
So you should install 64bit version
As per my understanding, A 32 bit OS will allows the keep the RAM or utilize the RAM upto 2powe32 kb's. mean's the server will allows you the operation;s of memory upto 2power32 kbs ....similarly 64 bit..2powerof 64.
you can install a 32bit in 64 bit os..but you cannot install 64bit SQL Server in 32 bit OS
Related
Here is what I have:
Problem: Trying to connect two different 64-bit applications:
Microsoft Access 64-bit
QuickBooks Entrprise 21.0 (I'm not sure if it is actually 32-bit or 64-bit)
Using:
Visual Studio 2022 64-bit edition
VB.NET
64-bit version of QBFC15 library for QuickBooks
My thought is that when you use a 64-bit API, it would connect to a 64-bit application. I am most likely incorrect.
When I connect to MS Access in the debug 64-bit mode, it connects fine. The Intuit developer Network says you need to publish applications in the 32-bit mode. I have always used the 32-bit mode for publishing QuickBooks applications because they were 32-bit programs and, well, frankly, 64-bit applications hadn't come out yet (no old person jokes here). Anyway, I was really excited to see that the 64-bit version of a QBFC library came out (QBFC15) and they offer both 32-bit and 64-bit. So I downloaded the 64-bit version (which they recommend on their site https:\\developer.intuit.com>
So I'm thinking, hey, it's a 64-bit SDK! Yeah! So now I have this project that tells me I need to connect a 64-bit Access application to QuickBooks. When I debug, my new application connects just fine to MS Access in the 64-bit mode! Yeah! But the 64-bit Intuit SDK needs to be published in the 32-bit mode!!!! I'm confused. I know that they have put the cart before the horse and I know that they must still be running QuickBooks Enterprise in the 32-bit mode but come on. Putting out the SDK before the commercial product comes out to use it one? (I'm done whining now...got to get it out somehow!).
So how am I to connect my application to both "64-bit" programs when one errors in the 32-bit mode and the other errors in the 64-bit mode?
The programming isn't the issue, but this scenario seems really problematic. Do I tell the customer they need to downgrade their Microsoft Office to the 32-bit mode version? That would be an easy answer I guess, but it sure makes me look bad. Any other suggestions out there that could help me in this would be much appreciated.
If you running desktop edition of QuickBooks, then if you are running a x32 bit version of QuickBooks?
Then that means automation and working with the desktop edition means your software ALL MUST remain x32.
Only in 2022, have they rather recent upgraded and offer a x64 bit verison.
So, you have to check which desktop version of QuickBooks you are running. (most up to rather recent have been x32 bits - for a VERY long time).
So, what determines what QBFC library, what version of Access, and quite much vb.net?
You must continue to force your vb.net projects to run as x86, and NOT use "any" CPU and not use x64.
So, what will determine what all of your code is to run as?
It will be the desktop edition of QB that determines this.
It is of ZERO use to adopt office x64, access x64, or run your vb.net software, and the QBFC sdk and library as x64 bits if QuickBooks remains as x32.
(you using the wrong bit size and architecture here).
so, you have to be 100%, and in fact 200% sure
now, if QBFC is hitting the server database for QuickBooks, then that can be x64 bits but if you using the QB sdk and QBFC? Then that all must remain x32 bits until such time you upgrade the desktop edition of QuickBooks.
So, you have to REALLY but REALLY find out if in fact if you are running x32 QuickBooks for desktop, or x64 for desktop.
The version of QuickBooks and what version you you THEN much choose of QBFC library, vb.net, Access/office then again will have to match the bit size of QuickBooks desktop.
So from everything else from down to Access to vb.net to QBFC then all again much match the version of QuickBooks for desktop you have installed.
Now, if vb.net, Access you use is NOT to interface via the QBFC .dll and SDK? Then you don't care. But, inter process communication based on so called "windows COM objects"? And say upgrading from office x32, and the associated software systems you have? You can't just out of the blue decide to jump to office x64 without say your company and IT department not knowing the difference between x32 bit software, and that of x64 bit software.
Hint: 8 bit Apple II computer has a different architecture then a 16 bit IBM PC. And going from 16 bits to x32 bits? Again, a huge and large jump.
And from x32 bit software to x64 bit software? again a huge jump.
So, while windows can happy run x32 bit software, and it been a x64 bit OS by default for 10+ years?
Well, software packages running as x32 bits, and them interfacing to x64 bit software is a whole different matter. Such software has to remain the same bit size - and you can't have different bit size process on windows such as x32 bit COM objects (ole, COM, ActiveX = same technology stack).
So keep this basic knowledge and hallmark and pillar in our industry - different bit size software systems can't talk to each other via inter-op, or so called COM object automation.
Post was rewritten after additional investigation. The error message was:
Installation of this product failed because it is not supported on this operating system. For information on supported configurations, see the product documentation.
The installation target is a Hyper-V guest machine as follows: 2G RAM, 14.5 GB free on the C: drive, 2.5 GHz CPU. .NET 3.5 is turned on.
On this page https://www.microsoft.com/en-us/download/details.aspx?id=42299 the following note was confusing to me (bold is my emphasis):
Note: Microsoft® SQL Server® 2014 Express includes both 32-bit and 64-bit versions. SQLEXPR32_x86 is a smaller package that can be used to install SQL Server 2014 Express onto only 32-bit operating systems. SQLEXPR_x86 is the same product but supports installation onto both 32-bit and 64-bit (WoW) operating systems. SQLEXPR_x64 is a native 64-bit SQL Server 2014 Express and supports installation onto only 64-bit operating systems. There is no other difference between these packages. Microsoft® SQL Server® 2014 Express is not supported on IA64 systems.
The wording seemed to indicate the x86.exe would work on both 32/64 bit systems which was consistent with my findings. But I thought that also indicated the 32bit.msi would also work on both 32/64 bit systems. I am beginning to believe I misunderstood and would appreciate confirmation the error is my reading of the note.
Your error message answers your question. Your trying to install it on an unsupported OS. Check out https://msdn.microsoft.com/en-us/library/ms143506(v=sql.120).aspx which lists the requirements. It appears that in a Hyper-V Environment all versions of SQL 2014 are only supported on a Windows 2008 SP2. 2008 R2 SP1, or 2012 OS.
My particular problem was the misunderstanding that the 32 bit MSI would work on a 64 bit OS. Once I changed to the 64 bit MSI SQL Express 2014 loaded just fine into the VM. The 32 bit x86 .exe setup file did in fact work on the 64 bit OS, just not the MSI setup file.
Note there are two different _x86 file names: SQLEXPR32_x86 only works on 32-bit systems. SQLEXPR_x86 (note the missing "32") will work on both 64-bit and 32-bit systems, but still runs as a 32-bit process.
Is it possible to load a 64-bit dll into a 32-bit process ?
Generally speaking, I know it can not happen.
Yet, maybe there are some exceptions ?
No, and neither a 64-bit process can load a 32-bit DLL.
If you're on a 64 bit OS, you can load the DLL in a 64-bit process and have it communicate with your 32-bit process through IPC.
If you're on a 32 bit OS, you're out of luck.
In .NET, it is possible to load a 64-bit DLL into a 32-bit process for reflection only. For details please check "Analyze 64-bit DLL from within T4 template in Visual Studio (32-bit) using Reflection".
I know that this is a special case, but I thought I'd add it anyway because it might help others looking for a similar solution as me.
Yes, you can load 64 code in 32 bit module. example:
vmprotect
metatrader4
above software mixed x86 and x64 in one process.
I found metatrade4 for win7 has a function it exeucte a instruction like :
jmp 0x33:0x175328
segment selector 33 is a 64bit segment. after execution this instruction, cpu will switch to 64bit mode from 32bit mode.
if you use windbg to trace some windows api on windows x64 OS, you will find similar code.
for example:
NtQueryInformationProcess
But new computer bought today at least have 4G ram. We cannot prevent using 64-bit OS to avoid problem. We must face 64-bit positively! Server 2008 R2 only have 64-bit.
Issues around EXE AnyCPU / x86, 32-bit COM / C++ dll must be handled.
Ideally compile both 32 and 64 bit COM / C++ dll.
Microsoft has a SQL server either as 32 bit or 64bit, however the 64bit contains both 32bit AND 64 bit.
are there any MSI packages containing the 32 bit AND 64 bit version of the ODBC connector ?
i.e. the install package decides by itself which version to install`?
Unfortunately, MSI is not very good at providing a single installer that works for both 32-bit and 64-bit systems. The 32-bit installer will not be able to write to the locations where the 64-bit files should be stored, and the 64-bit installer will not start on a 32-bit system.
Does a 64-bit CruiseControl.NET exist or do I need to install the 32-bit version? Our CI server is Server2003 64-bit. Currently I have been testing on WinXP Pro and no problems.
If I do need to run cc.net 32-bit on a 64-bit OS, what issues should I expect to encounter? This post mentions a couple, Running 32-bit ASP.NEt 3.5 apps in Windows 2003 64-bit . I would also need to have the .NET 2.0 and 3.5 framework installed. Do I install the 32-bit versions if running cc.net 32-bit? Can 32-bit and 64-bit coexist on the same server?
A quick peek at the source code reveals that CruiseControl.NET is compiled with "Any CPU" platform, so it will (and does) run on either a 32 or 64 bit runtime.
My notebook runs 64 bit O/S and has no problems with CruiseControl.NET server or web dashboard (IIS 7). Just install it as per normal and you should be fine.
Personally I'd be really worried if it needed > 3GB of memory :)
It shouldn't be anything you need to worry about. Cruise control just launches the build, subsequent steps such as compilation can be 64-bit.
I don't think there's much benefit from making CruiseControl 64-bit at the moment. I'm running CruiseControl without issues on a 64-bit machine. The setup was not much different, other than the folder which it was installed into (Program files (x86)).
Generally speaking, all 32bit applications will work on a 64bit OS. I have been doing this with my webapps for some time. You will encounter issues only if you are trying to reference assemblies across the bit boundary, ie. 64bit assembly from 32bit application.
You should be already to run CC on 32bit mode on 64bit OS.
There are no seperate version of CruiseControl for 64-bit. But but you may run into an ASP.NET error if working with Win. Server 2008 and IIS7.
Workaround:
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe" -i
and
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe" -i "W3SVC/1/ROOT/ccnet"
NOTE: it is using Framework64 as this would not work for 32-bit.