November 2007 - Posts

Getting around Jet Engine not installed error on 64 bit Vista

There is a problem with 64 bit Vista and that is the Jet Engine, used by ADO.NETs OleDb Data Provider, is not supported. It's also no longer supported by Microsoft so a 64 bit version is not planned. If you develop with OleDb on 64 bit Vista you get an error saying something along the lines of the Jet Engine is not installed.

The solution to the problem is fairly straightforward and that is any application you write that uses OleDb should target the x86 CPU architecture. This forces your application to run in 32 bit mode. The application still runs in 64 bit under WOW64 so there is no problem. You change this setting using the Configuration Manager in Visual Studio or by compiling your application with the /platform:x86 switch.

This is fine for your own developments but what about applications you get that use OleDb and have been compiled with the AnyCPU option. With out source code your pretty much stuck, all OleDb calls will fail. However, after a bit of poking about in the invaluable MSDN library I came across one little piece of information that allows you to get around the problem.

On 64 bit Windows operating systems a DLL (read assembly) compiled with AnyCPU will execute on the same CLR as the process into which it is loaded. Interesting, because since an EXE file is also an assemby that means if you can load and execute an EXE in a process targetting the 32 bit CLR then you can get an compiled application, targeting AnyCPU and using OleDb, to run in 32 bit mode, meaning OleDb will work of 64 bit.

The good thing is you can do this with only a couple of lines of code.

using System;
using System.Collections.Generic;
using System.Text;

using System.Reflection;

namespace ApplicationStarter
{
	class Program
	{
		[STAThreadAttribute()]
		static void Main(string[] args)
		{
			AppDomain.CurrentDomain.ExecuteAssembly(@"C:\Application.exe");
		}
	}
}

if you place the above into an console application and make that application ttarget the x86 architecture then the specified application is executed in the 32 bit process and any OleDb calls that are made will work, no need to recompile. You need to use the STAThreadAttribute as you'll get a runtime error if you don't.
Posted by dsmyth

VistaDb (100% Managed Database Engine)

Wow it's been a while, sorry for the lack of updates. It is due to a combination of studying for the MCPD (second attempt is looming) and having a bit of a deadline to meet on a project. I've been spending most of my time helping folks out on the MSDN forums. Many people ask me questions through this blog, although I really appreciate you coming and reading my blog, your best bet is to post to the forum. Much more likely to get your questions answered there.

Anyway found this wonderful fully managed database engine by the name of VistaDB, here is the link... it does look pretty amazing even though I've only had a small look.

http://www.vistadb.net/default.asp

This is a fully managed (written completely in C#) file based database engine that has less than a 1Mb foot print. It's like Access without the Jet Engine and it's like an SQL database without SQL Express. You create your database as a file, deploy it with your software along with a 1Mb DLL file (referenced by your project) and thats it, a fully functional database and engine. There isn't much of a learning curve as it uses all the ADO.NET objects you'll be familiar with, here a dummy example....

VistaDBConnectionStringBuilder connString = new VistaDBConnectionStringBuilder();
connString.OpenMode = VistaDB.VistaDBDatabaseOpenMode.NonexclusiveReadWrite;
connString.DataSource = "MyFirst.vdb3";

VistaDBConnection conn = new VistaDBConnection(connString.ConnectionString);

VistaDBCommand cmnd = new VistaDBCommand("SELECT * FROM [Employee]", conn);
conn.Open();

VistaDBDataReader readr = cmnd.ExecuteReader();
while (readr.Read())
{ 
//and so on
}

conn.Close();

Fantastic, all you need to specify is the connection string which at its most basic is "Data Source = 'C:\databaseFile.vdbc3'"

There are some limitations (although not that many) and the only one I can think of is there is no TSQL Stored Procedures, but there are CLR Stored Procedures. These are, from the look of things, method calls from assemblies that are embedded into the database. Really thats about the only limitation I can really find and there is a question of performance but I can not comment on it as I haven't ran any benchmarks.

To be honest though it's worth looking at and I know I'm going to be buying a copy. No need for your users to install anything, no SQL Express, no Jet Engine (which is not supported on 64 bit). Ideal.  It also has XML support in that you can build a database from a schema and import XML data in, and I'm guessing out. It has CLR Triggers, Referential Integrity, Views, and have I said... I'm getting a copy. Cheap as chips.