SqlCeException on application's first use of SQL CE

We discussed how SQL CE get's into trouble of failing to load SQL CE DLLs in an earlier blog article "Can't load SQLCE DLL".  As you can see this occurs when SQL CE is trying to load the native engine.  Note that, SQL CE delay loads the DLLs and hence the trouble.  Hence, we suggested in the earlier blog article to pre-load all required SQL CE DLLs so that you give chance to load SQL CE DLLs when there is memory. 

This issue shows up on the following instances:

1) Application is trying to fill the datagrid using SqlCeDataAdapter.Fill (or DbDataAdapter.Fill)

2) Application is trying to do merge replication with the backend server using SqlCeReplication.Synchronize

3) Application is trying to perform RDA operations with the backedn server using SqlCeRemoteDataAccess.Pull, SqlCeRemoteDataAccess.Push, or SqlCeRemoteDataAccess.SubmitSQL

With that context, and coming to what is different from our earlier versions is being discussed in this article.  As said in the above articles, application developers are requested to pre-load SQL CE DLL.  If you have chosen to go with pre-load approach and did a LoadLibrary("sqlcese30.dll") earlier, then it requires a little change.

SQL CE v3.0 released before we moved onto desktop.  Once we moved to desktop (in addition to device) with SQL CE v3.1 release, lot of customers started developing applications that work both on device and desktop.  One of the differences our customers came back was the installation model.  On desktops, we install under %ProgramFiles%\Microsoft SQL Server Compact Edition\v3.1 and on device we install under \Windows\.  We worked on that feedback and unified our installation in SQL CE v3.5.  That is, with SQL CE v3.5 onwards you can see that we always install under Program Files irrespective of the platform.  However, at the same time we did not want our customers to hardcode the installation folders.  So, we unified our registry keys too.  With SQL CE v3.5 SP1, you can use the registry key "HKLM\Software\Microsoft\Microsoft SQL Server Compact Edition\v3.5\InstallDir" to find the install location. 

Now coming back to troubleshooting, earlier Load Library calls with out path qualification worked on devices as we were under \Windows and hence the path probe was successful.  Now with our unification, we moved to a non-standard path and hence path probe would have failed and so was your LoadLibrary.  Hence, we request application developers to update their code to read registry and then use Load Library with full path so that you never worry about our changing install locations.  We strongly recommend you to use the registry to find the installation location as sometimes we may need to be under (\Windows) especially when going IN-ROM hence registry is always realiable model than hardcoded installation path.  I agree that you are hardcoding registry path than directory path, but we guaranty that registry path remains static for a version,  but not installation folder.

Thanks,

Laxmi Narsimha Rao Oruganti