"Jet database engine stopped the process" error

[Guest]

Randomly and infrequently (maybe 5 times a year), our users get the following
error message:

The Microsoft Jet database engine stopped the process because you and
another user are attempting to change the same data at the same time.

When the user gets it, we have verified that nobody else is in the database.
It's an Access 2003 (on SP2) front end, linked to Oracle tables. The user
gets the error when she tries to delete the record from the Oracle table. It
looks like the record is getting locked for that one person - she can close
Access and come back in multiple times, but she will get the error message
each time she tries to delete it. However, if a different user goes intot he
database, they can delete the record with no problems.

It doesn't seem to be an issue with the user's access because she can go to
a different record, in the same table, and delete it with no problems.

There also seems to be no rhyme or reason as to who gets the error message.
It is not consistently the same person who gets the error. There are around 8
or 9 users who have access to the database..

 

[aaron.kempf]

yeah.. DUH

MDB is a crappy ass engine SPIT on anyone that uses it

Access Data Projects is a superior project
throw away MDB; throw away Oracle and build simple apps with ADP.

I for one-- have experienced this exact same problem with MDB against
SQL Server-- WHY DO YOU THINK I HATE MDB SO MUCH?

-Aaron

 

[Smartin]

Randomly and infrequently (maybe 5 times a year), our users get the following
error message:

The Microsoft Jet database engine stopped the process because you and
another user are attempting to change the same data at the same time.

When the user gets it, we have verified that nobody else is in the database.
It's an Access 2003 (on SP2) front end, linked to Oracle tables. The user
gets the error when she tries to delete the record from the Oracle table. It
looks like the record is getting locked for that one person - she can close
Access and come back in multiple times, but she will get the error message
each time she tries to delete it. However, if a different user goes intot he
database, they can delete the record with no problems.

It doesn't seem to be an issue with the user's access because she can go to
a different record, in the same table, and delete it with no problems.

There also seems to be no rhyme or reason as to who gets the error message.
It is not consistently the same person who gets the error. There are around 8
or 9 users who have access to the database..

I've also seen the message occasionally also in a DB shared by about 7
users. If memory serves me, it seems to happen when we have a corrupt
record in the Access BE. Don't know if that would apply to you as you
say you have Oracle BE.

 

[aaron.kempf]

yeah.. it happens intermittently and the common denominator is _MDB_

why do you think that im so PISSED OFF ABOUT MDB?
because im sick and tired of MDB causing locking problems on a
production SQL Server and I get called in at 2am to fix it

-Aaron

 

[Smartin]

yeah.. it happens intermittently and the common denominator is _MDB_

why do you think that im so PISSED OFF ABOUT MDB?

yeah, I think I've read something along that line before

because im sick and tired of MDB causing locking problems on a
production SQL Server and I get called in at 2am to fix it

I hope you're paid by the hour (^:

OK wait, seriously, how does MDB cause locking problems on SQL server?

 

[aaron.kempf]

because it's unreliable.. because it's unscalable.. because it's
unpredictable.

it causes locks on SQL Server all the time.. check out sp_who2 and it
leaves connections open; it locks records

if you use MDB for anything that you need to use NOLOCK almost
everywhere because you're GOING to have locking problems

 

[aaron.kempf]

so why do you still use it??

I mean seriously here Smartin, please explain why you use a program
that 'corrupts records'

I've never gotten 'corrupt records' in SQL Server natively

 

[Smartin]

so why do you still use it??

I mean seriously here Smartin, please explain why you use a program
that 'corrupts records'

I've never gotten 'corrupt records' in SQL Server natively

Well for starters, it isn't my baby. I walked into this episode already
in progress...

Admittedly, it isn't perfect, no way, no how. It isn't even properly
configured for multiple users. So I expect problems. When I say
"occasionally" I mean that. I've seen this issue maybe once every other
month, an improvement since I tweaked the code with a one-liner
modification.

It simply isn't worth it (cost effective) to redesign it at this point.
The application I was speaking of isn't mission-critical and redoing the
thing simply is not worth the effort. If I had to build it from scratch,
or if this was a serious impediment to the business, that would be a
bird of another colour, but, it isn't that way. It works 99.5% of the
time or better. That's really all we need.

I'd love to transform this into a robust error-tolerant multi-user
application but the resources required to do that simply are not
justified in this case. I have to choose my battles.

Regards,

 

[aaron.kempf]

it is cost effective to translate MDB to ADP.

Maybe if you, and the other people around here used the BEST PLATFORM
IN THE WORLD then it wouldn't be so difficult.

5 times a year; it confused a half dozen users a piece. a couple of
tech support calls and a couple of developers looking for a resolution?

sounds like a $20,000 fix in your situation would be worth the ROI

you could probably do it for a lot less than this; it really depends on
how complex the app is.

I just dont think that you should choose to play Russian Roulette with
your DATA.

-Aaron