Possible causes for Access Violation exception in general:

 

An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value.

In programs consisting entirely of verifiable managed code, all references are either valid or null, and access violations are impossible. An AccessViolationException occurs only when verifiable managed code interacts with unmanaged code or with unsafe managed code.

 

For more information about this, please visit this link.

 

When this exception can be related to SQL Server Compact:

 

SQL Server Compact ADO.NET provider DLL [System.Data.SqlServerCe.dll] is a managed DLL which interacts with other native DLLs to provide the functionality.

 

There are two known issues related to the usage of SQL Server Compact provider which may lead to this Access Violation exception:

 

1.      Version Mismatch [3.5 RTM and 3.5 SP1]:

 

Access Violation occurs when the loader loads different versions of Managed and Native SQL Server Compact 3.5 DLLs. This issue arises when different versions are available in the box and this happens with Private and Central deployment of SQL Server Compact 3.5.

 

To be specific, if SQL Server Compact 3.5 RTM is pre-installed [centrally deployed] in the box and application built on top of SQL Server Compact 3.5 SP1 privately deploys the SQL Server Compact DLLs.

 

In this case, the managed DLL [System.Data.SqlServerCe.dll v3.5.5692.0] will be loaded from private directory but the native DLLs [sqlceme35.dll, sqlceqp35.dll, etc. v3.5.5386.0] might get loaded from the central deployed directory.

 

If the application is built against SQL Server Compact 3.5 RTM and SQL Server Compact 3.5 SP1 is centrally deployed in the box then the application will start using SQL Compact 3.5 SP1 as there is a redirection entry which redirects an application (Compiled against 3.5 RTM) to use centrally deployed SQL Compact 3.5 SP1.

   

2.      Thread Safety:

 

SQL CE objects are not thread-safe and are not thread affinitive either. If an instance of SqlCeConnection or SqlCeTransaction is shared across threads without ensuring thread safety, then that may lead to Access Violation exception.

 

 

Work-around if the cause is related to SQL Server Compact:

 

For the above two issues, there are workarounds available which should be followed to avoid any Access Violation exception.

 

1.      Version Mismatch:

 

One should follow either of the given below approaches to avoid the Access Violation exception:

 

Scenario: Application built against SQL Server Compact 3.5 SP1 [to be deployed privately] and SQL Server Compact 3.5 RTM centrally deployed.

 

Solution:

1.  There should be only one version of SQL Server Compact [v3.5 RTM or v3.5 SP1] installed in the box. The version with which the application is not built against [v3.5 RTM] should be un-installed.

2.  Install SQL Server Compact [v3.5 SP1] centrally to avoid any future install mismatch.

 

Forum thread related to this issue can be found here.

 

2.      Thread Safety:

 

It is recommended that each thread should use a separate connection than sharing across. If there is really a need for sharing SQL CE objects across threads, then the application should serialize access to these objects.

 

Thanks,

Mohammad Imran.