By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,573 Members | 3,017 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,573 IT Pros & Developers. It's quick & easy.

Data Being Updated by Another User

P: n/a
JA
I keep getting this error:

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

There is no other user. I've tried moving the table to another database, by
importing, exporting, and by copy/pasting. I've tried a Make-a-new-table
query. I've tried copy/pasting the table within the same database.

I can put that table and another together in a select query, as long as I
don't specify any criteria, if I do, I get the error.

The only thing I can guess that might have caused this is that I put the
database on a jump drive and then pulled it out of its socket without doing
the Remove Hardware stuff.

Is there a way to undo this?

Thanks! JA

Jun 2 '06 #1
Share this Question
Share on Google+
10 Replies


P: n/a
How are you attempting to update the data? What objects are open in your
application?
Jun 2 '06 #2

P: n/a
Is there a way to undo this?


very hard to say based on what you've posted. it's not cause you didn't
remove the hardware. Jet returns that error when more than one process
attempts to edit the same record at once. There doesnt have to be two
seperate "users".

the usual cause for me is a combination of a bound for open while
trying to perform a recordset update in code... but anything could be
causing this. do you have more details?

Jun 2 '06 #3

P: n/a
JA
Rick and Bill,

I had 2 tables in a query, and when I would specify criteria to look for, I
would get the error - the query wouldn't open.

Also, when I tried to copy the table (that was giving the error), either
open or closed, I would get the error.

I'm not talented enough to do anything in code! :-)

But, I just Compacted and Repaired, and now it seems to be ok......

Well, I compacted and repaired, and now it is ok.
"BillCo" <co**********@gmail.com> wrote in message
news:11*********************@u72g2000cwu.googlegro ups.com...
Is there a way to undo this?


very hard to say based on what you've posted. it's not cause you didn't
remove the hardware. Jet returns that error when more than one process
attempts to edit the same record at once. There doesnt have to be two
seperate "users".

the usual cause for me is a combination of a bound for open while
trying to perform a recordset update in code... but anything could be
causing this. do you have more details?

Jun 2 '06 #4

P: n/a
I'm not talented enough to do anything in code! :-)
no talent required for vba, actually talent's a drawback (that's always
been my excuse!).

But, I just Compacted and Repaired, and now it seems to be ok......


glad that worked.... a little puzzeled - but all's well that ends well
:)

Jun 2 '06 #5

P: n/a
BillCo wrote:
I'm not talented enough to do anything in code! :-)


no talent required for vba, actually talent's a drawback (that's always
been my excuse!).

But, I just Compacted and Repaired, and now it seems to be ok......


glad that worked.... a little puzzeled - but all's well that ends well
:)


It's quite possible (likely even) that the message is a lie!

I realise this is a little late and I'm jumping in at that end but
yesterday I had to deal with precisely this problem. The cause was
corruption in a record (it was a Memo field - it's almost always a Memo
field ...). The solution was to create a new duplicate table and copy
all the rows before the corrupted row and all the rows after the
corrupted row into the new table. Then I deleted the old table and
renamed the new. NB you have to remove any table links first and
re-create them afterwards.

Jeff Bailey

Jun 3 '06 #6

P: n/a
Sounds like a good reason to put your memo fields in a separate table from
the one they're associated with and set up a 1:1 relationship, that way you
only have one relationship to delete and you only lose the contents of the
memo field affected

--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...
BillCo wrote:
I'm not talented enough to do anything in code! :-)


no talent required for vba, actually talent's a drawback (that's always
been my excuse!).

But, I just Compacted and Repaired, and now it seems to be ok......


glad that worked.... a little puzzeled - but all's well that ends well
:)


It's quite possible (likely even) that the message is a lie!

I realise this is a little late and I'm jumping in at that end but
yesterday I had to deal with precisely this problem. The cause was
corruption in a record (it was a Memo field - it's almost always a Memo
field ...). The solution was to create a new duplicate table and copy
all the rows before the corrupted row and all the rows after the
corrupted row into the new table. Then I deleted the old table and
renamed the new. NB you have to remove any table links first and
re-create them afterwards.

Jeff Bailey

Jun 3 '06 #7

P: n/a
Terry

In the words of the immortal Afferbeck Lauder "eggwetter gree"

Pity we can't learn from foresight as effectively as we learn from
hindsight!

Jeff

Terry Kreft wrote:
Sounds like a good reason to put your memo fields in a separate table from
the one they're associated with and set up a 1:1 relationship, that way you
only have one relationship to delete and you only lose the contents of the
memo field affected

--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...
BillCo wrote:
> I'm not talented enough to do anything in code! :-)

no talent required for vba, actually talent's a drawback (that's always
been my excuse!).
> But, I just Compacted and Repaired, and now it seems to be ok......

glad that worked.... a little puzzeled - but all's well that ends well
:)


It's quite possible (likely even) that the message is a lie!

I realise this is a little late and I'm jumping in at that end but
yesterday I had to deal with precisely this problem. The cause was
corruption in a record (it was a Memo field - it's almost always a Memo
field ...). The solution was to create a new duplicate table and copy
all the rows before the corrupted row and all the rows after the
corrupted row into the new table. Then I deleted the old table and
renamed the new. NB you have to remove any table links first and
re-create them afterwards.

Jeff Bailey


Jun 5 '06 #8

P: n/a
Don't know what you are talking about, this isn't foresight or hindsight.

I was saying that it would be better to have the memo fields in a separate
table, you could implement this fairly easily unless you have a large number
of tables with memo fields.
--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...
Terry

In the words of the immortal Afferbeck Lauder "eggwetter gree"

Pity we can't learn from foresight as effectively as we learn from
hindsight!

Jeff

Terry Kreft wrote:
Sounds like a good reason to put your memo fields in a separate table from the one they're associated with and set up a 1:1 relationship, that way you only have one relationship to delete and you only lose the contents of the memo field affected

--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...
BillCo wrote:
> > I'm not talented enough to do anything in code! :-)
>
> no talent required for vba, actually talent's a drawback (that's always > been my excuse!).
>
>
> > But, I just Compacted and Repaired, and now it seems to be ok...... >
> glad that worked.... a little puzzeled - but all's well that ends well > :)

It's quite possible (likely even) that the message is a lie!

I realise this is a little late and I'm jumping in at that end but
yesterday I had to deal with precisely this problem. The cause was
corruption in a record (it was a Memo field - it's almost always a Memo field ...). The solution was to create a new duplicate table and copy
all the rows before the corrupted row and all the rows after the
corrupted row into the new table. Then I deleted the old table and
renamed the new. NB you have to remove any table links first and
re-create them afterwards.

Jeff Bailey

Jun 5 '06 #9

P: n/a
Ah, got the first bit, if you'd said "egg wetter gree", I'd have got it
straightaway. I understand your second comment now.
--

Terry Kreft
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:fp********************@karoo.co.uk...
Don't know what you are talking about, this isn't foresight or hindsight.

I was saying that it would be better to have the memo fields in a separate
table, you could implement this fairly easily unless you have a large number of tables with memo fields.
--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...
Terry

In the words of the immortal Afferbeck Lauder "eggwetter gree"

Pity we can't learn from foresight as effectively as we learn from
hindsight!

Jeff

Terry Kreft wrote:
Sounds like a good reason to put your memo fields in a separate table from the one they're associated with and set up a 1:1 relationship, that way
you
only have one relationship to delete and you only lose the contents of the memo field affected

--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...
> BillCo wrote:
> > > I'm not talented enough to do anything in code! :-)
> >
> > no talent required for vba, actually talent's a drawback (that's always > > been my excuse!).
> >
> >
> > > But, I just Compacted and Repaired, and now it seems to be ok...... > >
> > glad that worked.... a little puzzeled - but all's well that ends well > > :)
>
> It's quite possible (likely even) that the message is a lie!
>
> I realise this is a little late and I'm jumping in at that end but
> yesterday I had to deal with precisely this problem. The cause was
> corruption in a record (it was a Memo field - it's almost always a Memo > field ...). The solution was to create a new duplicate table and

copy > all the rows before the corrupted row and all the rows after the
> corrupted row into the new table. Then I deleted the old table and
> renamed the new. NB you have to remove any table links first and
> re-create them afterwards.
>
> Jeff Bailey
>


Jun 6 '06 #10

P: n/a
Off Topic

Sorry for the confusing eggwetter bit. I've been a fan of a small book
by Afferbeck Lauder, called Fraffly Well Spoken, since about 1970!

My current favourite expression is:

May kerosene furry pears ...

So I'll have to catch the bus!
Terry Kreft wrote:
Ah, got the first bit, if you'd said "egg wetter gree", I'd have got it
straightaway. I understand your second comment now.
--

Terry Kreft
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:fp********************@karoo.co.uk...
Don't know what you are talking about, this isn't foresight or hindsight.

I was saying that it would be better to have the memo fields in a separate
table, you could implement this fairly easily unless you have a large

number
of tables with memo fields.
--

Terry Kreft
<jb********@aol.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...
Terry

In the words of the immortal Afferbeck Lauder "eggwetter gree"

Pity we can't learn from foresight as effectively as we learn from
hindsight!

Jeff

Terry Kreft wrote:
> Sounds like a good reason to put your memo fields in a separate table

from
> the one they're associated with and set up a 1:1 relationship, that way
you
> only have one relationship to delete and you only lose the contents of

the
> memo field affected
>
> --
>
> Terry Kreft
>
>
> <jb********@aol.com> wrote in message
> news:11**********************@i39g2000cwa.googlegr oups.com...
> > BillCo wrote:
> > > > I'm not talented enough to do anything in code! :-)
> > >
> > > no talent required for vba, actually talent's a drawback (that's

always
> > > been my excuse!).
> > >
> > >
> > > > But, I just Compacted and Repaired, and now it seems to be

ok......
> > >
> > > glad that worked.... a little puzzeled - but all's well that ends

well
> > > :)
> >
> > It's quite possible (likely even) that the message is a lie!
> >
> > I realise this is a little late and I'm jumping in at that end but
> > yesterday I had to deal with precisely this problem. The cause was
> > corruption in a record (it was a Memo field - it's almost always a

Memo
> > field ...). The solution was to create a new duplicate table and

copy > > all the rows before the corrupted row and all the rows after the
> > corrupted row into the new table. Then I deleted the old table and
> > renamed the new. NB you have to remove any table links first and
> > re-create them afterwards.
> >
> > Jeff Bailey
> >



Jun 6 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.