Pocket Access connection and SQL CE connection on same device == ISSUES?

[Andrew Martin]

All-

I'm supporting an application that is written in VB.net with two SQL
CE databases: One for local data, one to be replicated to SQL Server
(Call this APPLICATION_1). APPLICATION_1 works fine on a 2002 device,
but when we install to a device running an emVB application that
writes to a Pocket Access .cdb (Call this APPLICATION_2) - we get
issues. Specifically, APPLICATION_1 dies on SQL CE Replication with a
non-specific SQL CE Exception (got people working on trapping more
detailed errors).

The connection strings are different, the intended datastores are
different, they run on separate "runtimes" (APPLICATION_1 = .NET CF,
APPLICATION_2 = pvbload.exe). In theory these applications should not
have anything to do with eachother. Any ideas are appreciated.

TIA -a

 

[Ilya Tumanov [MS]]

Andrew,

The only possible reason I have in mind is a low memory condition.
GC runs automatically if managed application needs more memory, but not the
native one (i.e. SQL CE).
Second application will reduce amount of available memory and could cause a
failure.

I would suggest you run GC and wait for finalizers to complete before
starting replication as follows:

GC.Collect();
GC.WaitForPendingFinalizers();

Please let me know if this works.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

 

[Andrew Martin]

Andrew,

The only possible reason I have in mind is a low memory condition.
GC runs automatically if managed application needs more memory, but not the
native one (i.e. SQL CE).
Second application will reduce amount of available memory and could cause a
failure.

I would suggest you run GC and wait for finalizers to complete before
starting replication as follows:

GC.Collect();
GC.WaitForPendingFinalizers();

Please let me know if this works.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

That is our thought, but we did some memory checks and it seems that
the device has sufficient memory (findings posted below).

The error that we trapped is: 27750
"Cannot load sscemw20.dll or ssceca20dll is missing or not
registered."

This error implies that there is an open connection somewhere being
effected by APPLICATION_2. I'm not sure how that would be the case
with a separate datasource, but I can't be sure. We do have 2 sdf
files in APPLICATION_1, but the other sdf connection is closed before
we perform the replication.

Thanks again for your considerations.

-a

Memory findings:

This is the device that is running only APPLICATION_1:
Steady state (no apps running)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 3.02
Free 16.52 28.52

Only our APPLICATION_1 running (but not replicating)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 9.57
Free 16.52 21.97

Only our APPLICATION_1 running (replicating)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 12.95
Free 16.52 18.69

After APPLICATION_1 replication and not doing anything else (but
APPLICATION_1 is running)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 11.73
Free 16.52 19.74

APPLICATION_1 replication was performed a few more times to ensure
that there is not a memory leak but there were no appreciable changes.

This is the device with APPLICATION_2:
Steady state (no apps running)
MEMORY Storage Program
Allocated 37.84 25.30
In Use 22.38 3.38
Free 15.46 21.92

Only APPLICATION_2 running
MEMORY Storage Program
Allocated 31.60 25.30
In Use 15.08 6.60
Free 16.52 18.70

We cannot test with APPLICATION_1 and APPLICATION_2 running because
the device crashes.

 

[Andrew Martin]

That is our thought, but we did some memory checks and it seems that
the device has sufficient memory (findings posted below).

The error that we trapped is: 27750
"Cannot load sscemw20.dll or ssceca20dll is missing or not
registered."

This error implies that there is an open connection somewhere being
effected by APPLICATION_2. I'm not sure how that would be the case
with a separate datasource, but I can't be sure. We do have 2 sdf
files in APPLICATION_1, but the other sdf connection is closed before
we perform the replication.

Thanks again for your considerations.

-a

We put in the GC calls, and the same error persists. This leads me to
believe that APPLICATION_2 somehow has a hold of a connection that is
causing us issues with Replication on APPLICATION_1. Is this possible
since APPLICATION_2 is emVB/emC++ and connecting to Pocket Access? Do
they in any way use sscemw20.dll or ssceca20.dll? I have found no
documentation to suggest it. If memory is not the issue, what else
could it be?

Thanks -a

 

[Andrew Martin]

That is our thought, but we did some memory checks and it seems that
the device has sufficient memory (findings posted below).

The error that we trapped is: 27750
"Cannot load sscemw20.dll or ssceca20dll is missing or not
registered."

This error implies that there is an open connection somewhere being
effected by APPLICATION_2. I'm not sure how that would be the case
with a separate datasource, but I can't be sure. We do have 2 sdf
files in APPLICATION_1, but the other sdf connection is closed before
we perform the replication.

Thanks again for your considerations.

-a

A little more information. It seems that APPLICATION_2 calls the
Access .cdb a couple times up front for application config values.
Then, throughout the application, it calls the Access .cdb
periodically to write to a log file. Perhaps this connection is
persistent and causing our issue?

 

[Ilya Tumanov [MS]]

Andrew,

Most likely, this error indicates 'no memory' problem.
Since your application works (at least from time to time), this native DLL
is not missing and is registered.
Thus, the only reason it can not be loaded is due to low memory.

While it appears you have plenty of memory, it might be unavailable to your
application.
Remember 640K limit problem? Oops, we did it again, sorry... Please read
this for more details:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/htm
l/advmemmgmt.asp

Now, how to fix it... Since GC alone is not enough, you will have to
dispose of all objects with underlying native parts you might live without.
This includes SqlCeEngine, SqlCeCommand, SqlCeConnection, SqlCeTransaction,
SqlCeReplication and SqlCeDataReader.
In fact, if it's in a SqlServerCe or SqlClient namespace and got Dispose()
on it - it should be disposed of.

I know it's a common practice to create and keep several SqlCeCommand
objects, but each eats up a bit of precious virtual memory.
Dispose of them, collect, and wait for finalizers.

Please let me know how it goes...

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

From: (e-mail address removed) (Andrew Martin)
Newsgroups: microsoft.public.dotnet.framework.compactframework
Subject: Re: Pocket Access connection and SQL CE connection on same device == ISSUES?
Date: 7 Oct 2003 19:19:19 -0700
Organization: http://groups.google.com
Lines: 130
Message-ID: <[email protected]>
References: <[email protected]>

NNTP-Posting-Host: 32.100.245.177
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1065579559 15634 127.0.0.1 (8 Oct 2003 02:19:19 GMT)
X-Complaints-To: (e-mail address removed)
NNTP-Posting-Date: Wed, 8 Oct 2003 02:19:19 +0000 (UTC)
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-onlin
e.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-
xit-09!supernews.com!postnews1.google.com!not-for-mail
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.compactframework:35389
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in message

Andrew,

The only possible reason I have in mind is a low memory condition.
GC runs automatically if managed application needs more memory, but not the
native one (i.e. SQL CE).
Second application will reduce amount of available memory and could cause a
failure.

I would suggest you run GC and wait for finalizers to complete before
starting replication as follows:

GC.Collect();
GC.WaitForPendingFinalizers();

Please let me know if this works.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

-------------------- ==
ISSUES?
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-onlin
e.de!newsfeed.freenet.de!newsfeed.news2me.com!elnk-nf2-pas!elnk-pas-nf1!news
feed.earthlink.net!sn-xit-02!sn-xit-06!sn-xit-09!supernews.com!postnews1.goo
gle.com!not-for-mail

That is our thought, but we did some memory checks and it seems that
the device has sufficient memory (findings posted below).

The error that we trapped is: 27750
"Cannot load sscemw20.dll or ssceca20dll is missing or not
registered."

This error implies that there is an open connection somewhere being
effected by APPLICATION_2. I'm not sure how that would be the case
with a separate datasource, but I can't be sure. We do have 2 sdf
files in APPLICATION_1, but the other sdf connection is closed before
we perform the replication.

Thanks again for your considerations.

-a

Memory findings:

This is the device that is running only APPLICATION_1:
Steady state (no apps running)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 3.02
Free 16.52 28.52

Only our APPLICATION_1 running (but not replicating)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 9.57
Free 16.52 21.97

Only our APPLICATION_1 running (replicating)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 12.95
Free 16.52 18.69

After APPLICATION_1 replication and not doing anything else (but
APPLICATION_1 is running)
MEMORY Storage Program
Allocated 31.60 31.54
In Use 15.08 11.73
Free 16.52 19.74

APPLICATION_1 replication was performed a few more times to ensure
that there is not a memory leak but there were no appreciable changes.

This is the device with APPLICATION_2:
Steady state (no apps running)
MEMORY Storage Program
Allocated 37.84 25.30
In Use 22.38 3.38
Free 15.46 21.92

Only APPLICATION_2 running
MEMORY Storage Program
Allocated 31.60 25.30
In Use 15.08 6.60
Free 16.52 18.70

We cannot test with APPLICATION_1 and APPLICATION_2 running because
the device crashes.

 

[Andrew Martin]

Andrew,

Most likely, this error indicates 'no memory' problem.
Since your application works (at least from time to time), this native DLL
is not missing and is registered.
Thus, the only reason it can not be loaded is due to low memory.

While it appears you have plenty of memory, it might be unavailable to your
application.
Remember 640K limit problem? Oops, we did it again, sorry... Please read
this for more details:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncenet/htm
l/advmemmgmt.asp

Now, how to fix it... Since GC alone is not enough, you will have to
dispose of all objects with underlying native parts you might live without.
This includes SqlCeEngine, SqlCeCommand, SqlCeConnection, SqlCeTransaction,
SqlCeReplication and SqlCeDataReader.
In fact, if it's in a SqlServerCe or SqlClient namespace and got Dispose()
on it - it should be disposed of.

I know it's a common practice to create and keep several SqlCeCommand
objects, but each eats up a bit of precious virtual memory.
Dispose of them, collect, and wait for finalizers.

Please let me know how it goes...

Best regards,

Ilya

Ok - So I cut down the .sdf to have only a few records, and built very
pared down applications to emulate both. I have suffuciently
convinced myself that it's not a memory issue (unless there is some
nasty freak temporary memory leak going on).

I believe the issue comes down to the fact that APPLICATION_2 has a
hold of one of the .cdb files it uses which causes the error:

-if APPLICATION_1 is open, APPLICATION_2 fails on load.
-APPLICATION_1 fails to replicate if APPLICATION_2 is open.

I found the following interesting bit today:

1. Open APPLICATION_2 to it's main page (which, in theory, does not
have an open connection):
2. Go to File Explorer
3. Copy ‘\Program Files\APPLICATION_2\db1.cdb'
4. Paste the db1.cdb to the ‘\' device root
5. The error message, "Cannot copy ‘db1': There has been a sharing
violation. The source or destination file may be in use." is
displayed.

Note – didn't get this error when performing the same steps with
db2.cdb indicating only the one table is active.

This tells me that although APPLICATION_2 may not be performing
queries or inserts against db1.cdb, it still has some sort of handle
to the db1 that may be causing the issue. My research has also
brought me to the fact that Pocket Access (like SQL CE) connections
must singular so the fact that APPLICATION_1 causes APPLICATION_2
issues may be related to this connection issue.

I'm looking further into how APPLICATION_2 handles the handle to db1,
but I'm rather concerned that if this in fact the issue, there may not
be a way to get these two applications to co-exist. This is a rather
large deployment so buying two devices for each site is not
financially viable.

Thanks again all,
-a

 

[Andrew Martin]

Ok - So I cut down the .sdf to have only a few records, and built very
pared down applications to emulate both. I have suffuciently
convinced myself that it's not a memory issue (unless there is some
nasty freak temporary memory leak going on).

In the continuing thread to myself, I'm going to reverse myself again.
Although it's not an obvious memory issue - it certainly is a memory
issue of some sort. With APPLICATION_2 running, and on the initial
call to our .sdf:

LocalSystem.DatabaseFile = "System.sdf"
LocalSystem.DatabaseUser = LOCAL_DB_LOGIN
LocalSystem.DatabasePassword = LOCAL_DB_PASSWORD
LocalSystem.DatabasePath = "\Program
Files\APPLICATION_1\System.sdf"

Try
Dim conn As System.Data.SqlServerCe.SqlCeConnection
Dim cmd As System.Data.SqlServerCe.SqlCeCommand
Dim dtr As System.Data.SqlServerCe.SqlCeDataReader
Dim SQL As String

conn = New
System.Data.SqlServerCe.SqlCeConnection(LocalSystem.ConnectionString)
conn.Open()

Native Exception. 0x80000002 (out of memory(?), but there is PLENTY of
memory)


In reverse, with APPLICATION_1 running, opening APPLICATION_2 also
throws an exception if it fails to load a dll. I'm still working on
having APPLICATION_2 trap a more detailed error (e.g. Which dll).

I'm trying to make more sense of your msdn article. My initial read
was a little out of my confort area.

Thanks,
-a

 

[Andrew Martin]

Ilya-

Read the article and now completely understand the issue.

With APPLICATION_2 open first, APPLICATION_1 gets Native Exception out
of memory when trying to conn.open which is likely trying to load
ssceca20.dll or something.

With APPLICATION_1 open first, APPLICATION_2 with better error
managment gets "Could not load library:
\Windows\SOME_APPLICATION_DLL.dll"

I just got a response from the APPLICATION_2 developer that they use
18 dlls!

That has to be it.

-a