SQL Anywhere ultralite - Database corruption

Author

Database corruption

Jonathan Chapman

2006-02-28, 8:27 pm

Hi,

I have a problem where my .Net Compact Framework application running on
Pocket PC 2003 will get a fatal exception in the Ultralite library and
crash. When I restart the application I cannot get back into the database.
When I take a look at the database with ulisql.exe it tells me that "Request
to start/stop database denied (-75)". What could be causing this
corruption? How can I recover from it?

It seems to only happen on a single AudioVox 6600 with the database on a 256
MB SD Card. Are there any known issues with this hardware? The database
itself is 3 MB.

The Ultralite version is 9.0.2 Build 3131. Compact Framework is 1.0.

Thanks,
Jonathan

Jonathan Chapman

2006-03-05, 8:29 pm

Correction on the hardware it is actually an AudioVox 6600 with a 512 MB
High speed SD card.

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:4404a6c4$1@foru
ms-1-dub...
> Hi,
>
> I have a problem where my .Net Compact Framework application running
on
> Pocket PC 2003 will get a fatal exception in the Ultralite library and
> crash. When I restart the application I cannot get back into the
database.
> When I take a look at the database with ulisql.exe it tells me that
" Request
> to start/stop database denied (-75)". What could be causing this
> corruption? How can I recover from it?
>
> It seems to only happen on a single AudioVox 6600 with the database on a
256
> MB SD Card. Are there any known issues with this hardware? The database
> itself is 3 MB.
>
> The Ultralite version is 9.0.2 Build 3131. Compact Framework is 1.0.
>
> Thanks,
> Jonathan
>
>

Michael Thode

2006-03-05, 8:29 pm

It sounds to me like a hardware issue, there is a possiblity it could be an
Ultralite issue as well.

Have you tried different SD cards?
Have you tried it on more than one AudioVox 6600?
How hard is the problem to reproduce? How frequently have you seen the
problem?

Mike

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:4405c9d2$1@foru
ms-1-dub...
> Correction on the hardware it is actually an AudioVox 6600 with a 512 MB
> High speed SD card.
>
>
> "Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
> news:4404a6c4$1@foru
ms-1-dub...
> on
> database.
> "Request
> 256
database[color=darkr
ed]
>
>

Jonathan Chapman

2006-03-05, 8:29 pm

We have done some more testing with our client and have not yet been able to
solidly reproduce the issue but it looks like it may have to do with
synching while losing network coverage or having the power turned off during
the synch. It does not happen all the time when we do this but will cause
the Fatal Error every once in a while, and ultimately the database to be
corrupted. We are doing the additional testing on a different handheld so
it doesn't look like it's the handheld now. I'm not sure if the memory card
was the same on this unit as it is the client that is seeing the problem. I
will try to find out.

Is there any way to recover from a corrupt database?

Jonathan

"Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
news:4406087c$1@foru
ms-1-dub...
> It sounds to me like a hardware issue, there is a possiblity it could be
an
> Ultralite issue as well.
>
> Have you tried different SD cards?
> Have you tried it on more than one AudioVox 6600?
> How hard is the problem to reproduce? How frequently have you seen the
> problem?
>
> Mike
>
> "Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
> news:4405c9d2$1@foru
ms-1-dub...
running[color=darkre
d]
a[color=darkred]
> database
>
>

Michael Thode

2006-03-05, 8:29 pm

In general, no there is reliable way to recover a corrupted database.
Having backups by synchronizing the data or by physically copying the file
is the way to protect against lossing data.

It sounds like you are doing exactly the right things to narrow down the
problem. You could also try pulling out the SD card during sync to see if
that causes any problems. On a bug free device Ultralite should never
corrupt the database even if the power goes out, network goes down or if you
SD card is pulled out in the middle of an operation.

If you get a reliable repro and think it may be an Ultralite issue then you
can open a tech support case for this. Till then I'd suggest plugging away
as you are and use the newsgroup to discuss any ideas or questions you have.

Mike

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:44061144$1@foru
ms-1-dub...
> We have done some more testing with our client and have not yet been able
to
> solidly reproduce the issue but it looks like it may have to do with
> synching while losing network coverage or having the power turned off
during
> the synch. It does not happen all the time when we do this but will cause
> the Fatal Error every once in a while, and ultimately the database to be
> corrupted. We are doing the additional testing on a different handheld so
> it doesn't look like it's the handheld now. I'm not sure if the memory
card
> was the same on this unit as it is the client that is seeing the problem.
I
> will try to find out.
>
> Is there any way to recover from a corrupt database?
>
> Jonathan
>
>
> "Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
> news:4406087c$1@foru
ms-1-dub...
> an
MB[color=darkred]
> running
and[color=darkred]
on[color=darkred]
> a
1.0.[color=darkred]
>
>

Jonathan Chapman

2006-03-05, 8:29 pm

I took your suggestion to try removing the card while synching. This does
cause the same Fatal Error that crashes the app. However, it does not
corrupt the database. I expect that the Ultralite dll would throw a
exception that can be caught when this happens. Your thoughts?

Jonathan

"Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
news:4406243a$1@foru
ms-2-dub...
> In general, no there is reliable way to recover a corrupted database.
> Having backups by synchronizing the data or by physically copying the file
> is the way to protect against lossing data.
>
> It sounds like you are doing exactly the right things to narrow down the
> problem. You could also try pulling out the SD card during sync to see if
> that causes any problems. On a bug free device Ultralite should never
> corrupt the database even if the power goes out, network goes down or if
you
> SD card is pulled out in the middle of an operation.
>
> If you get a reliable repro and think it may be an Ultralite issue then
you
> can open a tech support case for this. Till then I'd suggest plugging
away
> as you are and use the newsgroup to discuss any ideas or questions you
have.
>
> Mike
>
>
> "Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
> news:44061144$1@foru
ms-1-dub...
able[color=darkred]
> to
> during
cause[color=darkred]

so[color=darkred]
> card
problem.[color=darkred]
> I
be[color=darkred]
the[color=darkred]
512[color=darkred]
> MB
> and
that[color=darkred]
database[color=darkr
ed]
> on
> 1.0.
>
>

Michael Thode

2006-03-07, 1:23 pm

One possible theory is that if an device error occurs while writing to the
card then the file may become corrupted. By pulling the card out, there is
no chance for the device to corrupt the file. This shows that Ultralite can
recover from a crash on your device.

When you say "Fatal Error" can you describe that more. Is this an OS fatal
error or an ultralite fatal sqlcode? Is this error raise right away, or is
there a delay? Ultralite shouldn't crash when a card is pulled. Perhaps
the OS isn't handling this error properly. Do you have another type of
device that you can test with? You can see if it gets the same results.
You could try writting a simple app that just writes bytes to a file then
pull the card during this write. The app shouldn't crash, it should just
return an error code from the file write call.

Were you able to narrow down if it was a network failure or a device power
down that was causing the initial problem?

Mike

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:4408c8c4@forums
-1-dub...
> I took your suggestion to try removing the card while synching. This does
> cause the same Fatal Error that crashes the app. However, it does not
> corrupt the database. I expect that the Ultralite dll would throw a
> exception that can be caught when this happens. Your thoughts?
>
>
>
> Jonathan
>
> "Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
> news:4406243a$1@foru
ms-2-dub...
file[color=darkred]
if[color=darkred]
> you
> you
> away
> have.
> able
> cause
be[color=darkred]
handheld[color=darkr
ed]
> so
memory[color=darkred
]
> problem.
could[color=darkred]

> be
> the
> 512
[color=darkred]
library[color=darkre
d]
the[color=darkred]
> that
this[color=darkred]
> database
>
>

Michal Seliga

2006-03-14, 11:23 am

i have maybe related problem (and maybe it should go to separate thread, i
simply don't know)

database is 9.0.2.3249, platform is palmos (code warrior9.3), i use c++ api

what happens is that on tungsten t|x devices we have almost guaranteed way to
get corrupted database. we never tried asa9 version of our application on
anything else because these are the only palmone devices available in shops at
the moment

steps are

1) work with t|x until dbcache memory will have only very little space
(this is ok for t|x because with palmos 5.4.9 there were some changes in nvfs
code and caching and it can work flawlessly even when you have almost no free space)

2) database is started

db=new ULData();

ULEnablePalmRecordDB
(&sqlca);
ULRegisterSchemaUpgr
adeObserver(& sqlca,SchemaObserver
,NULL);
switch (db->PalmLaunch(&synch_info))
{
case LAUNCH_SUCCESS_FIRST
:
...

case LAUNCH_SUCCESS:
...

case LAUNCH_FAIL:
...
}

3) now application works correctly but for some reason reset will happen (bug in
application or stupid user or some other reason). note that this reset is not
necessary, but if you want to make this problem appear faster it will help.
without reset you must play with applicaton (launch, exit, synchronize, ..) for
about 2-3 hours for this to happen.

4) next time when database is started there are 3 possibilities
a - everything works correctly
b - database will not start with error code - 108(SQLE_CONNECTION_
NOT_FOUND)
i can't find when exactly i got this error code (i didn't had good
logging) and it happened only once anyway (and on next tries it went
forward to possibility c)
c - t|x will reset itself while processing db->PalmLaunch(&synch_info).
unfortunately this possibility happens quite often.

5) when you got to point 4c then i found that ulisql sometimes can't open the
database saying that it is corrupted (sometimes it works) and when you try to
put this database to t|x debug simulator it will complain during processing
db->PalmLaunch that 'datamgr.c, Line:7437, Err getting rec (and you must reset
like on real device). When this happens metrowerks shows that
Stack dump:
???
reorderDatabase(void
*)

and error happens in this assembly code
032C69A8: 48E71F32 movem.l d3-d7/a2-a3/a6,-(a7)
032C69AC: 266F0024 movea.l 36(a7),a3
032C69B0: 2F0B move.l a3,-(a7)
032C69B2: 4E4F trap #15
032C69B4: A04F sysTrapDmNumRecords
032C69B6: 3C00 move.w d0,d6
032C69B8: 7800 moveq #0,d4
032C69BA: 4A46 tst.w d6
032C69BC: 584F addq.w #4,a7
032C69BE: 670000A4 beq.w reorderDatabase(void
*)+0x1b7c
(0x32c6a64); 0x032c6a64
032C69C2: 7E00 moveq #0,d7
032C69C4: 3E06 move.w d6,d7
032C69C6: 5387 subq.l #1,d7
032C69C8: 3F04 move.w d4,-(a7)
032C69CA: 2F0B move.l a3,-(a7)
032C69CC: 4E4F trap #15
032C69CE: A05C sysTrapDmGetRecord ;
crash happens here

it is also possible to make this happen it t|x debug simulator, but it is quite
unclean way (different then on real device because simulator behaves
differently) - you have to allocale big blocks of feature memory (which is taken
from dbcache) so there will be only little of it available after launch of
application (<100kb), then start database (it will work, even application will
work without any problems) and when you will close application reset simulator
(during processing PalmExit function). result will be the same like i wrote on
real device. but i am afraid that the way to get to this result is different
(after reset during closing database i am not suprised it can be corrupted) so i
personally don't believe it can help to track anything

i am trying to track it down to bug in my application, but i would like to know
if there are any known issues with t|x and ultralite, or if anyone has any idea
what could be cause of this?

Stella Lai

2006-03-14, 8:23 pm

A recent UL fix has been made in 9.0.2.3265+; on T|X devices running the
latest Palm OS v5.4.9, the OS can leave record busy bits turned on when
reset. This could cause UltraLite applications failing on startup in
ULAppLaunch.

- Stella Lai
iAnywhere Solutions

"Michal Seliga" <michal.seliga@visicom.sk> wrote in message
news:4416f243@forums
-1-dub...
>i have maybe related problem (and maybe it should go to separate thread, i
> simply don't know)
>
> database is 9.0.2.3249, platform is palmos (code warrior9.3), i use c++
> api
>
> what happens is that on tungsten t|x devices we have almost guaranteed way
> to
> get corrupted database. we never tried asa9 version of our application on
> anything else because these are the only palmone devices available in
> shops at
> the moment
>
> steps are
>
> 1) work with t|x until dbcache memory will have only very little space
> (this is ok for t|x because with palmos 5.4.9 there were some changes in
> nvfs
> code and caching and it can work flawlessly even when you have almost no
> free space)
>
> 2) database is started
>
> db=new ULData();
>
> ULEnablePalmRecordDB
(&sqlca);
> ULRegisterSchemaUpgr
adeObserver(& sqlca,SchemaObserver
,NULL);
> switch (db->PalmLaunch(&synch_info))
> {
> case LAUNCH_SUCCESS_FIRST
:
> ...
>
> case LAUNCH_SUCCESS:
> ...
>
> case LAUNCH_FAIL:
> ...
> }
>
> 3) now application works correctly but for some reason reset will happen
> (bug in
> application or stupid user or some other reason). note that this reset is
> not
> necessary, but if you want to make this problem appear faster it will
> help.
> without reset you must play with applicaton (launch, exit, synchronize,
> ..) for
> about 2-3 hours for this to happen.
>
> 4) next time when database is started there are 3 possibilities
> a - everything works correctly
> b - database will not start with error
> code - 108(SQLE_CONNECTION_
NOT_FOUND)
> i can't find when exactly i got this error code (i didn't had good
> logging) and it happened only once anyway (and on next tries it
> went
> forward to possibility c)
> c - t|x will reset itself while processing db->PalmLaunch(&synch_info).
> unfortunately this possibility happens quite often.
>
> 5) when you got to point 4c then i found that ulisql sometimes can't open
> the
> database saying that it is corrupted (sometimes it works) and when you try
> to
> put this database to t|x debug simulator it will complain during
> processing
> db->PalmLaunch that 'datamgr.c, Line:7437, Err getting rec (and you must
> reset
> like on real device). When this happens metrowerks shows that
> Stack dump:
> ???
> reorderDatabase(void
*)
>
> and error happens in this assembly code
> 032C69A8: 48E71F32 movem.l d3-d7/a2-a3/a6,-(a7)
> 032C69AC: 266F0024 movea.l 36(a7),a3
> 032C69B0: 2F0B move.l a3,-(a7)
> 032C69B2: 4E4F trap #15
> 032C69B4: A04F sysTrapDmNumRecords
> 032C69B6: 3C00 move.w d0,d6
> 032C69B8: 7800 moveq #0,d4
> 032C69BA: 4A46 tst.w d6
> 032C69BC: 584F addq.w #4,a7
> 032C69BE: 670000A4 beq.w reorderDatabase(void
*)+0x1b7c
> (0x32c6a64); 0x032c6a64
> 032C69C2: 7E00 moveq #0,d7
> 032C69C4: 3E06 move.w d6,d7
> 032C69C6: 5387 subq.l #1,d7
> 032C69C8: 3F04 move.w d4,-(a7)
> 032C69CA: 2F0B move.l a3,-(a7)
> 032C69CC: 4E4F trap #15
> 032C69CE: A05C sysTrapDmGetRecord ; crash happens here
>
> it is also possible to make this happen it t|x debug simulator, but it is
> quite
> unclean way (different then on real device because simulator behaves
> differently) - you have to allocale big blocks of feature memory (which is
> taken
> from dbcache) so there will be only little of it available after launch of
> application (<100kb), then start database (it will work, even application
> will
> work without any problems) and when you will close application reset
> simulator
> (during processing PalmExit function). result will be the same like i
> wrote on
> real device. but i am afraid that the way to get to this result is
> different
> (after reset during closing database i am not suprised it can be
> corrupted) so i
> personally don't believe it can help to track anything
>
> i am trying to track it down to bug in my application, but i would like to
> know
> if there are any known issues with t|x and ultralite, or if anyone has any
> idea
> what could be cause of this?

Michael Thode

2006-03-14, 8:23 pm

The fix described by Stella should fix your more frequent problem with the
reset case. However this won't address problems that occur without a reset
as well as the issue you described in 4b. So, once you get the latest EBF,
could you try to repro these issues again and report back on the results.

Mike

"Stella Lai" <slai@nospam.com> wrote in message
news:441727fd$1@foru
ms-1-dub...
>A recent UL fix has been made in 9.0.2.3265+; on T|X devices running the
>latest Palm OS v5.4.9, the OS can leave record busy bits turned on when
>reset. This could cause UltraLite applications failing on startup in
>ULAppLaunch.
>
> - Stella Lai
> iAnywhere Solutions
>
>
>
>
> "Michal Seliga" <michal.seliga@visicom.sk> wrote in message
> news:4416f243@forums
-1-dub...
>
>

Jonathan Chapman

2006-03-15, 9:23 am

We have been able to do more work with this and we are able to reproduce the
problem by turning the power on and off. So far when we do this during
database creation we get the "Specified database is invalid" error when we
try to restart the app. When we do it during synching we get the "Unable to
start specified database" error when we try to restart the app. In both
cases when we initially do it we get a Fatal Exception. For these latest
test we have upgrade to 3267.

Thanks,
Jonathan

"Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
news:440dda03$1@foru
ms-1-dub...
> One possible theory is that if an device error occurs while writing to the
> card then the file may become corrupted. By pulling the card out, there
is
> no chance for the device to corrupt the file. This shows that Ultralite
can
> recover from a crash on your device.
>
> When you say "Fatal Error" can you describe that more. Is this an OS
fatal

> error or an ultralite fatal sqlcode? Is this error raise right away, or
is
> there a delay? Ultralite shouldn't crash when a card is pulled. Perhaps
> the OS isn't handling this error properly. Do you have another type of
> device that you can test with? You can see if it gets the same results.
> You could try writting a simple app that just writes bytes to a file then
> pull the card during this write. The app shouldn't crash, it should just
> return an error code from the file write call.
>
> Were you able to narrow down if it was a network failure or a device power
> down that was causing the initial problem?
>
> Mike
>
>
> "Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
> news:4408c8c4@forums
-1-dub...
does[color=darkred]
> file
the[color=darkred]
see[color=darkred]
> if
if[color=darkred]
then[color=darkred]
off[color=darkred]
to[color=darkred]
> be
> handheld
> memory
> could
seen[color=darkred]
a[color=darkred]
message[color=darkre
d]
>
application[color=da
rkred]
> library
> the
> this
The[color=darkred]
is[color=darkred]
>
>

Michal Seliga

2006-03-15, 9:23 am

Michael Thode wrote:
> The fix described by Stella should fix your more frequent problem with the
> reset case. However this won't address problems that occur without a reset
> as well as the issue you described in 4b. So, once you get the latest EBF,
> could you try to repro these issues again and report back on the results.
>

reset problem is fixed with last EBF, we had no more problems with this, only
-108 problem happened much more often

this is path how to get this -108 (by our tester)

- launch application (PalmLaunch(...),open connection)
- close it (PalmExit...)
- synchronize using hotsync
- launch application (PalmLaunch(...), reopen connection)
- reset handheld (or simulator)
- after reset make another hotsync, but make sure mobilink is not running (so
synch. will fail)
- launch application again (Palmlaunch(...), reopen connection will return -108)

I was able to fix it in my code. problem was that when ULConnection::Reopen
()
returned -108 i didn't called ULConnection::Open(...) but just showed error
message and gave up (without calling ULData::PalmExit(...)). when application
was started another time database was gone (it was re-created empty). in
simulator i got similar error messages as with previous ebf after reset.

also i found that when i use new C++ api (ULDatabaseManager::
OpenConnection(...)
and then attach this connection to ULConnection by function you gave me some
time ago then there is no such problem. it happens only with ULConnection::Reopen

so it seems it was my bug, sorry for bothering

Jonathan Chapman

2006-03-15, 11:23 am

In addition we sometimes get the
SQLE_START_STOP_DATA
BASE_DENIED error when it happens during synch

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:44182a6a$1@foru
ms-1-dub...
> We have been able to do more work with this and we are able to reproduce
the
> problem by turning the power on and off. So far when we do this during
> database creation we get the "Specified database is invalid" error when we
> try to restart the app. When we do it during synching we get the "Unable
to
> start specified database" error when we try to restart the app. In both
> cases when we initially do it we get a Fatal Exception. For these latest
> test we have upgrade to 3267.
>
> Thanks,
> Jonathan
>
> "Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
> news:440dda03$1@foru
ms-1-dub...
the[color=darkred]
> is
> can
> fatal
> is
Perhaps[color=darkre
d]
then[color=darkred]
just[color=darkred]
power[color=darkred]

> does
database.[color=darkred]
the[color=darkred]
> the
> see
never[color=darkred]

or[color=darkred]
> if
> then
plugging[color=darkr
ed]
you[color=darkred]
been[color=darkred]
with[color=darkred]
> off
will[color=darkred]
> to
> seen
message[color=darkre
d]
with[color=darkred]
> a
> message
> application
into[color=darkred]
me[color=darkred]
> The
Framework[color=dark
red]
> is
>
>

Jonathan Chapman

2006-03-15, 1:23 pm

Another Update...

Before my latest crash I received an
SQLE_MEMORY_ERROR

Then when I logged back into the app I get the Request to start/stop
database denied error. Can I recover when I see SQLE_MEMORY_ERROR?

Thanks

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:44182a6a$1@foru
ms-1-dub...
> We have been able to do more work with this and we are able to reproduce
the
> problem by turning the power on and off. So far when we do this during
> database creation we get the "Specified database is invalid" error when we
> try to restart the app. When we do it during synching we get the "Unable
to
> start specified database" error when we try to restart the app. In both
> cases when we initially do it we get a Fatal Exception. For these latest
> test we have upgrade to 3267.
>
> Thanks,
> Jonathan
>
> "Michael Thode" < mthode_no_spam@sybas
e.com> wrote in message
> news:440dda03$1@foru
ms-1-dub...
the[color=darkred]
> is
> can
> fatal
> is
Perhaps[color=darkre
d]
then[color=darkred]
just[color=darkred]
power[color=darkred]

> does
database.[color=darkred]
the[color=darkred]
> the
> see
never[color=darkred]

or[color=darkred]
> if
> then
plugging[color=darkr
ed]
you[color=darkred]
been[color=darkred]
with[color=darkred]
> off
will[color=darkred]
> to
> seen
message[color=darkre
d]
with[color=darkred]
> a
> message
> application
into[color=darkred]
me[color=darkred]
> The
Framework[color=dark
red]
> is
>
>

Michael Thode

2006-03-16, 7:28 am

Two possible theories.

1. On power up/down there is an inadvertent write to the flash causing a
corruption.
2. Data is not being properly flushed to the flash on power down.

I think 2 is more likely than 1 because you'd be seeing issues with other
files on the flash card if that was the case.

To narrow this down you can write an app to try and simulate this case

loop {
write a large amount of data to a file
call FlushFileBuffers
read the data back in and verify its what you wrote out.
}

The added complication that I skipped above is that CE closes file handles
on external cards on power down. So if you get an error reading or writing
you'll need to reopen the file and try the read/write again before
preceeding.

While running this power up/down the device and see if you can make the
verification fail.

Mike

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:44184ba4@forums
-1-dub...
> In addition we sometimes get the
> SQLE_START_STOP_DATA
BASE_DENIED error when it happens during synch
>
> "Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
> news:44182a6a$1@foru
ms-1-dub...
> the
> to
> the
> Perhaps
> then
> just
> power
> database.
> the
> never
> or
> plugging
> you
> been
> with
> will
> message
> with
> into
> me
> Framework
>
>

Michael Thode

2006-03-16, 7:28 am

In general yes, but in this case the memory error is probably a side effect
of an earlier corruption.

Mike

"Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
news:44187489$1@foru
ms-1-dub...
> Another Update...
>
> Before my latest crash I received an
> SQLE_MEMORY_ERROR
>
> Then when I logged back into the app I get the Request to start/stop
> database denied error. Can I recover when I see SQLE_MEMORY_ERROR?
>
>
>
> Thanks
>
> "Jonathan Chapman" < jonathan_chapman@ape
xsi.com> wrote in message
> news:44182a6a$1@foru
ms-1-dub...
> the
> to
> the
> Perhaps
> then
> just
> power
> database.
> the
> never
> or
> plugging
> you
> been
> with
> will
> message
> with
> into
> me
> Framework
>
>

Sponsored Links