A while back I posted some info about our intention to ship a native 64bit release: SQL Server Compact and 64bit support discussing how developers that use Compact on 64bit machines needed to use WoW mode.
I’m happy to say our 64bit release is coming soon. We’ve actually been working on this for a while. It’s not as easy as it might seem. There were several issues to make this work that cover all our scenarios including:
- Private Deployment – including the dlls directly within your project
- Which also includes how to load a private version of 64bit when 32 is centrally installed, or the other way around
- Opening a database from multiple processes
- Sharing the same database across devices, desktops and servers
We originally hoped to get this done with 3.5 RTM last November, but with the added complications, we just needed some extra time. Because SQL Server Compact supports multiple processes opening the same database, and we wanted to share the same file format across device, desktop, 32 and 64bit machines, we had a lot of extra work to do to make sure all those bytes aligned. When working on 64bit operating systems, there was some extra work we needed to do to make sure 32 and 64bit machines could support the same file format and X-Process communications. In addition to the scenarios where developers use Compact as a “document format” that can be emailed or posted to a sharepoint site, we know developers often pre-create the .sdf on the server, sync it, then stream it down to the client (device, 32 bit desktop, 64bit desktop).
Ease of deployment
When building your application, how many processor types do you need to build? Should your users need to know whether they should have to install the 32 or 64bit versions? Devs – maybe. End users? Why should they know or care. To ease this model, we took on some extra work to make sure developers could build one version of their application, including both the 32bit and 64bit version of Compact directly within their application. This means developers can build one version, their users install one version, and at runtime our System.Data.SqlServerCe.dll will automatically load the appropriate engine.
So, the good news is:
- We use the exact same file format between device, 32bit desktop, 64bit desktop scenarios.
- You can also open the same database from a 32bit process and 64bit process. For those that don’t know, Visual Studio actually runs in WoW mode, even on 64bit machines.
- You can build one version of your app, and your users can install one version and it will “just work”
The not so good news
- RTM and SP1 will not work completely interchangeably. While we caught the file format issue early, we didn’t catch the shared memory issue early enough to fix in RTM. We use shared memory to open the same database across two processes. So, this means if you have an application that uses Compact 3.5 RTM, and another that uses Compact 3.5 SP1 (64 bit), you won’t be able to open the same file at the same time. The first one will win. If you simply update the RTM app to SP1, all will be good.
What 64bit platforms are supported
As a general rule, AMD64 is our supported 64bit clients, so that does mean we won’t have the IA64bit release. Do many of you actually use the Itanium server boxes? If so, would they be needed for your “web servers” where you’re likely to need SQL Server Compact?
When will it ship?
Our 64bit release will be available as a Web Download when we ship SQL Server Compact SP1. This will align with the Visual Studio 2008 SP1 and SQL Server 2008 ship dates. So, not very far out.
Will there be a beta?
With the tight timeframes, we didn’t see a lot of value in doing a beta. The reality is by the time we get the beta up, there’s really no time for feedback. There’s actually a lot involved in shipping betas between EULAs and such. If you really, really, really want to give it a try before we ship, we are doing external validation with a few key customers, so just send me a note and we’ll see what we can do.
What components will be available?
As many of you know, we ship several components.
- Server Tools for Merge Replication
Of course we don’t yet have 64bit devices, so nothing here. But we will be shipping the desktop and server tools in AMD64 bit versions.
Lastly, I figured I’d be proactive on a comment around the complexities of shipping native 64bit code, and how this is a bit more complicated for developers to privately deploy native code. Today, we do ship SQL Server Compact as a native engine for our storage engine and query processor. There are other components such as the Merge Replication Client and a few other libraries that are native as well. While this does make privately deploying Compact a bit more difficult, there are some definite benefits in perf, scalability and stability. We’ve heard this over and over again that a database must be reliable, fast and consume minimal memory or what good is it. Otherwise, why not use XML? Today, the best way to do this is through native code. How long that remains to be true is a question for another day, but be assured we’re fully aware of the pros and cons to native and managed code and we are working with our friends in the CLR team to bring the .NET platform forward so it can perform even better for devices and support managed code in more and more interesting scenarios.
In the meantime, know that we’re “on it”, and it’s coming soon.