How can I circument the "80004005 There is a file sharing violation...." err msg on a SQL Server CE database?

Question

I am getting error

80004005 There is a file sharing violation. A different process might be using the file.

when trying to open a SqlCeConnection.

Is there a way to close a SQL Server CE database programmatically, to try to nip that problem in the bud? Something like (pseudocode):

SqlCeDatabase SQLCeDb = "\My Documents\HHSDB003.sdf";

if (SQLCeDb.IsOpen)
{
    SQLCeDb.Close();
}

?

Or a way to set the connection so that it doesn't care if the database is open elsewhere/wise, such as:

SqlCeConnection conn = new SqlCeConnection(@"Data Source=\My Documents\HHSDB003.sdf;File Mode = 'shared read'");

...or:

SqlCeConnection conn = new SqlCeConnection(@"Data Source=\My Documents\HHSDB003.sdf;File Mode = 'read write'");

I can't test these at present, because I'm back to getting

Cannot copy HHS.exe The device has either stopped responding or has been disconnected

when I attempt to copy over a new version of the .exe to the handheld.

If there's something more frustrating to program against (and "against" is the correct word here, I think) than the prehistoric versions of Windows CE / Compact Framework / .NET, I'm not at all sure I want to know what it is.

UPDATE

Adding to my frustrusion (haywire combination of confusion and frustration), I found the following at http://www.pocketpcfaq.com/faqs/activesync/exchange_errors.php:

    0x80004005  N/A Synchronization failed due to a device software error. Contact your network administrator.      

1. Obtain the latest Pocket PC End User Update from your service provider.

UPDATE 2

Is this possibly problematic (than all but the first setting is blank):

UPDATE 3

With this code:

private void menuItemTestSendingXML_Click(object sender, System.EventArgs e)
{
    string connStr = "Data Source=My Documents\\HHSDB003.SDF"; 

    SqlCeConnection conn = null;

    try
    {
        try
        {
            conn = new SqlCeConnection(connStr);
            conn.Open();
            MessageBox.Show("it must have opened okay");
        }
        finally
        {
            conn.Close();
        }
    }
    catch (Exception ex)
    {
        if (null == ex.InnerException)
        {
            MessageBox.Show("inner Ex is null");
        }
        MessageBox.Show(String.Format("msg is {0}", ex.Message));
    }
}

...I am now seeing "it must have opened okay" (that's a good thing, but...why it's now working, I have no idea, because the code has not changed since I last ran it and it failed. Something beyond the code must have been at play.

The only thing I can think of that happened that MAY have had a bearing on this change is that, thinking there may have been a rogue instance of either the .exe or its ancillary dll in memory on the handheld device, I wrote an quick-and-dirty utility that looped through the running processes, looking for them and, if finding them, killing them, but they were not there, so the utility really did "nothing" (maybe the Hawthorne effect?).

That is the way working with this combination of tools and technologies seems to go, though: everything is working fine one minute and the next, BAM! It no longer is. Then the reverse can also happen: for no apparent reason it seems to "heal itself".

In the interests of "full disclosure," here is the utility code:

// Got this from http://www.codeproject.com/Articles/36841/Compact-Framework-Process-class-that-supports-full
private void btnKillRogue_Click(object sender, EventArgs e)
{
    ProcessInfo[] list = ProcessCE.GetProcesses();

    foreach (ProcessInfo item in list)
    {
        MessageBox.Show("Process item: " + item.FullPath);
        if (item.FullPath == @"\Windows\iexplore.exe") item.Kill(); //<= this was the example search; it probably could be a problem, so I'll use it, too
        if (item.FullPath.EndsWith("HHS.exe"))
        {
            MessageBox.Show("about to kill hhs.exe");
            item.Kill();
        }
        if (item.FullPath.EndsWith("HUtilCE.dll"))
        {
            MessageBox.Show("about to kill hutilce.dll");
            item.Kill();
        }
    }
}

Maybe there was an instance of iexplore.exe resident in memory that was problematic (I'm not showing a messagebox if that is what is found)...?

Answer 1

As an attempt to claim unused bounty ... do not, however, feel obligated to pass around free points on my behalf ...

Aside from force killing of possible tasks, had you rebooted the system amidst your search for an answer? If your tool did not return the message, it is certainly possible that a reboot would have done the very thing that you had attempted with the kill utility - or possible iexplore.exe had something to do with it ... the lack of the additional messagebox may leave you never knowing - unless this issue occurs again.

If no rebooting occurred, then perhaps whatever program/dll was held in memory by some other process concluded its task and released it hold.

There are several scenarios that might have occurred, it is certainly hard to determine with absolution; hence the lack of answers. I would be interested, though, if this problem occurred again.