Error 3051

[rdemyan via AccessMonster.com]

In 12 months of working on my app, I have never had a corruption problem with
the backends, often with the front end but never the backends.

So, of course, now that I'm planning to roll a new version of the app out
next week, I suddenly had a problem.

Here's the development configuration

1) Computer #1
a) Access 2000 - app is developed on this machine
b) A Folder on this machine acts as a test server folder for the backends:
Backend #1 and Backend #2

2) Computer #2
a) Access 2003 - client plans to switch soon, so I have to test A2003

So today, I suddenly got error 3051 when Computer #2 (A2003) linked to
Backend #1. This error is:

"The Microsoft Jet database engine cannot open the file 'Backend #1'. It is
already opened exclusively by
another user, or you need permission to view its data.

Backend #2 was linked fine.

Computer #1 did not have the app open so there was no other front end
attached to either backend. I checked for a .ldb file for Backend #1 and
there was none.

Yesterday, however, there was major bloat of this backend from 45 MB to 110
MB, so I compacted it yesterday on Computer #1. Today, was the first day that
I tried to open "compacted" Backend#1 on Computer #2. As noted, I received
error 3051.

HOWEVER, A2K on Computer #1 was able to link to "compacted" Backend#1 just
fine. I could open "compacted" Backend#1 on Computer #1 just fine, but not on
Computer #2 (same 3051 error).
Because I've never had a problem with a backend, I'm very bad about backing
up the backends. So, naturally, I didn't have a current copy to try. But I
did replace Backend #1 with a version that is about 1 month old. A2003 on
Computer #2 linked to it just fine.

So, I got around the problem by taking the month old Backend #1 backup and
deleting all tables in it. Then I imported all the tables from the current
"compacted" Backend #1 (the backend that caused Error 3051 with A2003 on
Computer #2) into the month old backup. Then I tried linking A2003 on
Computer #2 to the backend backup (with the imported current tables) and
everything worked just fine.

This is what drives me nuts about Access. How am I going to handle this kind
of problem when a client has this occur to them without getting personally
involved.

So, I'm posting because I'm hoping some developers might provide some insight,
experience on what they do to minimize such problems.

I am including a utility with my app that will use the Windows Task Scheduler
to backup the backends nightly, which should help, but I don't see how that
will stop this problem.

My limited experience with A2003, I just got it a week ago, is that it does
seem to be less prone to bloat and compacts to a smaller size.

But the really annoying thing is that the "damaged" backend file worked fine
with A2000, but not with A2003. Is this because the compact procedures are
different and may have caused the problem?

Thanks for any help. Once again, compact and repair leaves me very nervous.

--
Message posted via http://www.accessmonster.com

[Allen Browne]

You could try using A2000 to create a new (blank) database, disabling the
Name AutoCorrect options, remove all code references except the 2 required
ones, and then import the data from the old database (File | Get External |
Import.)

Run a compact/repair just to be sure, and you should now be able to use this
as the back end.

As you say, it is rare for the back end to corrupt. You might want to check
that both computers are using the same version of msjet40.dll (typically in
windows\system3 2), or at least 4.0.8xxx.0. (The minor version will probably
start with 9 on a fully patched Win2000 machine.) If you need the service
pack, you can reach it through:
http://support.microsoft.com/kb/239114

Other general suggestions for preventing corruption:
http://allenbrowne.com/ser-47.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"rdemyan via AccessMonster.c om" <u6836@uwe> wrote in message
news:5e7ccfdc7b 1e3@uwe...

In 12 months of working on my app, I have never had a corruption problem
with
the backends, often with the front end but never the backends.

So, of course, now that I'm planning to roll a new version of the app out
next week, I suddenly had a problem.

Here's the development configuration

1) Computer #1
a) Access 2000 - app is developed on this machine
b) A Folder on this machine acts as a test server folder for the backends:
Backend #1 and Backend #2

2) Computer #2
a) Access 2003 - client plans to switch soon, so I have to test A2003

So today, I suddenly got error 3051 when Computer #2 (A2003) linked to
Backend #1. This error is:

"The Microsoft Jet database engine cannot open the file 'Backend #1'. It
is
already opened exclusively by
another user, or you need permission to view its data.

Backend #2 was linked fine.

Computer #1 did not have the app open so there was no other front end
attached to either backend. I checked for a .ldb file for Backend #1 and
there was none.

Yesterday, however, there was major bloat of this backend from 45 MB to
110
MB, so I compacted it yesterday on Computer #1. Today, was the first day
that
I tried to open "compacted" Backend#1 on Computer #2. As noted, I
received
error 3051.

HOWEVER, A2K on Computer #1 was able to link to "compacted" Backend#1 just
fine. I could open "compacted" Backend#1 on Computer #1 just fine, but not
on
Computer #2 (same 3051 error).
Because I've never had a problem with a backend, I'm very bad about
backing
up the backends. So, naturally, I didn't have a current copy to try. But I
did replace Backend #1 with a version that is about 1 month old. A2003 on
Computer #2 linked to it just fine.

So, I got around the problem by taking the month old Backend #1 backup and
deleting all tables in it. Then I imported all the tables from the current
"compacted" Backend #1 (the backend that caused Error 3051 with A2003 on
Computer #2) into the month old backup. Then I tried linking A2003 on
Computer #2 to the backend backup (with the imported current tables) and
everything worked just fine.

This is what drives me nuts about Access. How am I going to handle this
kind
of problem when a client has this occur to them without getting personally
involved.

So, I'm posting because I'm hoping some developers might provide some
insight,
experience on what they do to minimize such problems.

I am including a utility with my app that will use the Windows Task
Scheduler
to backup the backends nightly, which should help, but I don't see how
that
will stop this problem.

My limited experience with A2003, I just got it a week ago, is that it
does
seem to be less prone to bloat and compacts to a smaller size.

But the really annoying thing is that the "damaged" backend file worked
fine
with A2000, but not with A2003. Is this because the compact procedures are
different and may have caused the problem?

Thanks for any help. Once again, compact and repair leaves me very
nervous.

[rdemyan via AccessMonster.com]

Hi Allen:

Thanks for the response. Your suggestions in previous posts and on your
website have really helped prevent corruption in my front end. Since I
started decompiling during development, I haven't experienced front-end
corruption in several months.

I essentially did what you suggested, but instead of a new database I used
one that was a month old and deleted all of the existing tables in it. Then
I imported the tables from the backend that was causing the problem with
A2003. This worked fine and A2003 could now link to the backend.

It seems to me that this might be an A2000 and A2003 issue. I've noticed
that A2K really bloats files. A2003 seems to compact to about half the size
I can achieve in A2K. But I don't know how susceptible it is to bloat. I'm
planning to do some tests where I import data to the backend tables via my
front end. The front end always bloats during the import (even though I
import the data to a holding table in a temporary database and all tables are
in the backend.). So I'll compare how A2K stacks up against A2003.

The version of Jet is the same on both PCs, namely version 4.0.8618.0.

Allen Browne wrote:

You could try using A2000 to create a new (blank) database, disabling the
Name AutoCorrect options, remove all code references except the 2 required
ones, and then import the data from the old database (File | Get External |
Import.)

Run a compact/repair just to be sure, and you should now be able to use this
as the back end.

As you say, it is rare for the back end to corrupt. You might want to check
that both computers are using the same version of msjet40.dll (typically in
windows\system 32), or at least 4.0.8xxx.0. (The minor version will probably
start with 9 on a fully patched Win2000 machine.) If you need the service
pack, you can reach it through:
http://support.microsoft.com/kb/239114

Other general suggestions for preventing corruption:
http://allenbrowne.com/ser-47.html

In 12 months of working on my app, I have never had a corruption problem
with

[quoted text clipped - 79 lines]

Thanks for any help. Once again, compact and repair leaves me very
nervous.

--
Message posted via AccessMonster.c om
http://www.accessmonster.com/Uwe/For...ccess/200604/1

[Jamey Shuemaker]

I've had similar funny-business and incompatability between A2k3 and
A2k. In fact, I've had to stop the two or three out of 50 or so
machines running A2k3 from running one of the apps. I had to dilute a
good bit of the code in one mdb and turn it into an mde so the A2k3
folks could continue using it. Never had time to trouble-shoot enough
to figure out exactly where the problems were, but the DB did have
several custom class modules that once removed stopped causing trouble.
Since then I've improved the object model and things have run smoothly.

I've been meaning to tinker with A2k3 for a couple weeks, but haven't
had the time or inclination since it's been running fine since the
mods. I did have a lot of troublesome code errors early after A2k3 was
installed on that handful of machines. I'd continue to play around with
both and make sure you game test everything thoroughly before cutting
the app loose on A2k3, especially if the app is code rich.

I've also had an OLE server/ActiveX control error pop up on an A2k2
machine opening a form that worked fine till A2k3 got its hands on it.
I've tried recreating the form and it's subform structure. Everythhing
works fine when the form's class module is removed, but once the
subform's class module (all of about 5 lines of code) is plugged back
in, the OLE server error pops up again. The error now pops up on either
A2k2 or A2k3, so I've got some work to do to figure that one out.

Happy hunting.

[Allen Browne]

Jamey, thank you for contributing your experience.

The fact that making an MDE helped suggests that the problem is (at least in
part) the kind of thing that a decompile solves. Each version of Access uses
a different compiled binary. Newer versions are able to use the binary of
the old, but not the reverse. So, if an A2003 machine modifies the binary in
some way, the A2000 machine has to recompile it in its binary, and so on.
This kind of thing does lead to weird and hard to track down errors.
Decompile solves the errors. Creating an MDE prevents it decompiling and so
the A2000 binary is stable in all versions.

Class modules are inherently less robust than standard modules. That does
not mean you cannot use them, but it does mean that you must be scrupulous
in the way you instantiate and destroy objects, and even then they are more
fragile. Again the MDE scenario could help, I suspect.

The OLE server/ActiveX error can be a symptom of the same problem (different
binaries corrupted). It could also be a symptom of a Name AutoCorrect error
if you have not yet turned that off in your application.

The artilce rdemyan was referring to about preventing corruption was
probably this one:
http://allenbrowne.com/ser-25.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Jamey Shuemaker" <ca*********@ya hoo.com> wrote in message
news:11******** **************@ z34g2000cwc.goo glegroups.com.. .

I've had similar funny-business and incompatability between A2k3 and
A2k. In fact, I've had to stop the two or three out of 50 or so
machines running A2k3 from running one of the apps. I had to dilute a
good bit of the code in one mdb and turn it into an mde so the A2k3
folks could continue using it. Never had time to trouble-shoot enough
to figure out exactly where the problems were, but the DB did have
several custom class modules that once removed stopped causing trouble.
Since then I've improved the object model and things have run smoothly.

I've been meaning to tinker with A2k3 for a couple weeks, but haven't
had the time or inclination since it's been running fine since the
mods. I did have a lot of troublesome code errors early after A2k3 was
installed on that handful of machines. I'd continue to play around with
both and make sure you game test everything thoroughly before cutting
the app loose on A2k3, especially if the app is code rich.

I've also had an OLE server/ActiveX control error pop up on an A2k2
machine opening a form that worked fine till A2k3 got its hands on it.
I've tried recreating the form and it's subform structure. Everythhing
works fine when the form's class module is removed, but once the
subform's class module (all of about 5 lines of code) is plugged back
in, the OLE server error pops up again. The error now pops up on either
A2k2 or A2k3, so I've got some work to do to figure that one out.

Happy hunting.

[David W. Fenton]

"rdemyan via AccessMonster.c om" <u6836@uwe> wrote in
news:5e7ccfdc7b 1e3@uwe:

So, I'm posting because I'm hoping some developers might provide
some insight, experience on what they do to minimize such
problems.

Sounds like an NTFS permissions problem. When you compact the
compacting user may be getting ownership of the file. Or it could be
that the permissions on the original file are set correctly, but the
permissions on the folder it's in are set differently.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Allen Browne" <Al*********@Se eSig.Invalid> wrote in
news:44******** *************** @per-qv1-newsreader-01.iinet.net.au :

The fact that making an MDE helped suggests that the problem is
(at least in part) the kind of thing that a decompile solves

Not necessarily. In the case of both compacting and creating an MDE,
you're writing a new file, but in the case of the MDE you're keeping
the old file. NTFS permissions will depend on the permissions set on
the parent folder, which will be inherited by the new file.

The way to test this is to compact without having the original file
open and then comparing the original permissions to the permissions
on the newly created compacted MDB.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Jamey Shuemaker]

Thanks Allen.

I spent some time looking through the suggestions there last evening,
and honestly, I've migrated toward pretty well all of the suggestions
there by mere survival instinct. I didn't do very much of that when I
first got started, but as I've developed more and more apps and more
and more as a developer, or hack, or whatever it is that I've become
over the last couple years, I've implemented pretty well every one of
those suggestions. Funny how those things work.

Anyways, didn't know about the name autocorrect issue. In fact, I just
had a discussion the other night about its merits with another
developer, though I haven't tested it to see just how fool proof it is.
I'll take your advice for now, regardless, and shut 'er down on the
projects I've got going, especially those with the A2K/A2k3
crossbreeding problems.

Regards,
Jamey

[Allen Browne]

That's great, Jamey.

Yes, most of the suggestions probably are reasonably intuitive to an
experienced developer.

Name AutoCorrupt is a real devil though. It is one of the first thing I
check out in any database I am asked to investigate, as it is the root of so
many evils.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Jamey Shuemaker" <ca*********@ya hoo.com> wrote in message
news:11******** *************@e 56g2000cwe.goog legroups.com...

Thanks Allen.

I spent some time looking through the suggestions there last evening,
and honestly, I've migrated toward pretty well all of the suggestions
there by mere survival instinct. I didn't do very much of that when I
first got started, but as I've developed more and more apps and more
and more as a developer, or hack, or whatever it is that I've become
over the last couple years, I've implemented pretty well every one of
those suggestions. Funny how those things work.

Anyways, didn't know about the name autocorrect issue. In fact, I just
had a discussion the other night about its merits with another
developer, though I haven't tested it to see just how fool proof it is.
I'll take your advice for now, regardless, and shut 'er down on the
projects I've got going, especially those with the A2K/A2k3
crossbreeding problems.

Regards,
Jamey