Embedded Firebird, error trying to write to file

This error has been really annoying me tonight!

I have an app that uses Embedded Firebird for its DB so that I don't need to
install a DB server. On Vista my app throws an exception "Error trying to
write to file (the correct path here)".

I recreated the DB on my development machine (XP) and tried running it, it should work, it has for months, but it didn't! The same error too!

For the life of me I couldn't work out why it would suddenly stop working on both machines, what did they have in common? I uninstalled stuff, reinstalled it, etc, no joy.

The answer on my XP box was simple. I used the local server to create the GDB file + generate my DB structure using ECO. What I hadn't thought of was the fact that the firebird server then holds a file handle open on that GDB file in case I want to use it again. Embedded firebird needs an exclusive lock on the file so this was the problem on my XP box. I wish the error had read something like "Error trying to write to file, unable to obtain an exclusive lock", would have saved me some time!

However, I don't have the firebird server installed on my Vista test machine so what was causing the problem there? It seems that embedded firebird cannot access the GDB on vista if it is in the CommonApplicationData folder. This is a real pain because

A: I need the database in a common place so that any user using the software will see the same data.
B: This is where it is supposed to go!

So doesn't the current user have sufficient privileges to write to this folder? The following snippet of test code says they do.

static void Main(string[] args)
{
  string fileName = Environment.GetFolderPath(System.Environment.SpecialFolder.CommonApplicationData);
  fileName = Path.Combine(fileName, "MyTest.txt");
  Console.WriteLine("Writing to " + fileName);
  StreamWriter sw = new StreamWriter(fileName);
  using (sw)
    sw.WriteLine("Hello");
  Console.WriteLine("Done");
  Console.ReadLine();
}

I have checked and the database file is in CommonApplicationData on the Vista machine, so it's not as though I am installing into the wrong folder or something either.

The only thing I can think of is that the UAC rules are different between .NET assemblies and native DLLs. It's the only thing I can think of, I really could do with a solution to this!



Pete