Transferdatabase canceled, error 2501

  • Thread starter Thread starter sTeve
  • Start date Start date
S

sTeve

I have an application that was upgraded from Access97 to 2002. It's a
linked app, the forms and tables are in seperate mdb files.

Each user has their own copy of the forms mdb on their local hard
drive.

There is a third mdb that contains common reports. In access 97, I've
written some vba code that does a docmd.transferdatabase to bring the
report into the user's forms mdb, run the report, then delete it.
That way, if the report is updated, they always run the most recent
copy.

The Transferdatabase and DeleteObject commands no longer work in 2002
if the application is opened via shortcut. They do work if the
application is opened by double clicking the forms.mdb file (ie,
opening the file exclusively).

I've tried modifying the tools --> options to open the db exclusively
by default, as well as modifying the shortcut with the /excl parameter
with no avail.

I've also read previous posts going back to 2000 about this problem.

Has anybody figured out what is going on and if there is a workaround
yet? Is there a way of programatically checking for another user and
then exclusively locking the mdb?

thank you,

Steve Shapiro
University of Oregon
 
That is a most unusual configuration you are using. If the issue is keeping
all the user copies up to date with the most current report, you could
consider moving the reports to the database with the forms. To ensure they
have the lasted copy of all object (not just reports), you can consider a
strategy like this:

http://www.granite.ab.ca/access/autofe.htm

It is highly unlikely the report objects change on a daily basis, so copying
them each time you run a report is degrading performance from the user's
perspective. Deleting and copying objects also contributes heavily to
database bloat.
 
On Mon, 10 Apr 2006 11:24:01 -0700, Klatuu

thanks for the reply.

It's actually a very efficient system, as it allows any user to create
new reports, which are then shared with all users.

We use a system similar to the one you provided the link to in order
to keep the users client mdb updated. We maintain two tables, one on
the server, one on the client. Every time the client opens their
forms.mdb, it compares the versions in the two tables. If they are
not equal, the local client version shuts down and executes a script
which copies the new mdb file to the client, then relaunches it. It's
very efficient, and the user is only bothered when there is a forms
change.

Over the long term database bloat is an issue, but they never get big
enough to be enough of an issue to warrent a fix.

What I'm really trying to understand is why the transferdatabase and
other database docmd. are not functioning.

thanx,

Steve
 
It sounds almost like a case of "not invented here". If you trust all
of your users to contribute useful and error free reports why not have
them send their reports to the master copy of the front end rather
than having a separate mdb to manage and access?? Once they make a
change to the master, have them also increment the version count. The
new version will have all of the reports, including the latest
contribution. Now you or any user need only look to the front end to
see ALL of its functionality. Occam's razor implies that simpler is
better.

As to your main concern, I don't know. But, if you implement your
application as suggested above it will be a non-issue as regards this
application. Another thought: are any of your references marked as
MISSING?

HTH
 
Back
Top