Run-Time Error 2501

[Guest]

I'm building an updater program with several forms and reports to be
transferred from the Updater program to the working copies of a program used
by
multiple users. I've built the updater using the TransferDatabase method.
In Access 97 I was getting a Run-Time Error 3420, but was able to overcome
this by adding error handling to resume the same line. However, now in
Access 2002 I am receiving a Run-Time Error 2501 'TransferDatabase action was
canceled' any time I try to use it for a Form or Report. Yet it seems to
work fine on Tables or Queries. I can't seem to find a way to overcome this
and whenever I click Help from the error message box, I get a blank help box.

Any ideas what would be causing the TransferDatabase action to be canceled
and how to make it not do that???

 

[Guest]

Are you specifying the correct object type?
Post the TransferDatabase code that is not working, please.

 

[Guest]

Dim db As Database
Dim path As String

On Error GoTo 1
path = Me.txtpath
Set db = OpenDatabase(path)

On Error GoTo Error_ObjectNotValid

DoCmd.TransferDatabase acExport, "Microsoft Access", path, acForm, "Post
Audit Form", "Post Audit Form", False
DoCmd.TransferDatabase acExport, "Microsoft Access", path, acReport, "Amend
To Zero - Chains", "Amend To Zero - Chains", False
MsgBox ("Your Audit Tool Updates are complete.")

Set db = Nothing
Exit Sub

1
MsgBox ("Your Auditing with ESI Tool could not be found at '" & path & "'.
Please re-type your path and try again.")
Exit Sub

 

[Guest]

what is in path? Is it a correct path to the database you want to put the
form in?

 

[Guest]

path is the path to the database U:\Desktop and C Drive Items for Transfer to
new Laptop\Auditing 06-01-05.mdb (the U drive is my person network storage
space on our company server).

 

[Guest]

The answer is not obvious. I would try playing with the path until I got it
to work.

 

[Guest]

It has nothing to do with the path. If the path were the problem, it would
error out when I tried to OpenDatabase. I even tried creating a new database

 

[Guest]

Sorry, I am lost here. I don't see the problem. There appears to be nothing
wrong with your code.

 

[Guest]

Thus the reason for my post. My code worked fine in Access 97, but now that
it's been converted to Access 2002 I am getting a run-time error 2501 'The
TransferDatabase action was canceled'. It's the same exact code. In
addition, tables will transfer, but not forms or reports.

 

[Guest]

I understand your problem, but not having worked in 2002 (I went from 2000 to
2003) I don't know what might be causing the problelm. Sorry I can't be of
more help.

 

[Ken Snell [MVP]]

How long is the string that the "path" variable contains? If I recall
correctly, the string cannot exceed 62 or so characters.

 

[Guest]

The string varies in length, however, I received the same error with a path
as short as C:\Test DB.mdb as I did with a path as long as U:\Desktop and C
Drive Items for Transfer to new Laptop\Auditing with ESI 06-01-05-AU.mdb

The second path is the actual path of the database I was trying to transfer
to, which is longer than the path which most of the employees would be using.
However, since it still didn't work with a path which is only 14 characters,
it doesn't appear that string length is the problem. Not to mention that the
"path", whatever it may be works fine with the TransferDatabase action for
tables.

 

[Ken Snell [MVP]]

So you want to export the forms to the database listed in path? You are
opening that database before you do the export, and that may not allow
ACCESS to "lock" it for doing the export. Comment out the OpenDatabase line
and try it again.

 

[Guest]

Okay, not sure what's happening now, but it's NOT good. I commented out the
OpenDatabase and ran the code through for 8 letters into the test database.
They transfered. Then I ran the code to transfer to an actual copy of the
database. When I opened the database to confirm that the modified reports
were in the database, they were all missing. Not even the original reports
were in there. I tried to import the reports manually from the updater
database, and they won't import (even after running a repair). I try to open
ANY of the forms in the database and it errors out stating Module Not Found.
I try to run a Compile and it errors saying such and such report name entered
in the property sheet or macro refers to a report that doesn't exist. If I
import any form or report which was not included as part of the
TransferDatabase code, they will import and display fine; it's only those
reports I tried to transfer into the database using the code in the updater.

 

[Ken Snell [MVP]]

Did the target database already contain the forms that you were exporting to
it? Did you delete them in the target database before you exported to it?

I never use the export method from code; instead, the code is in the target
database to import the objects from another database when I want to copy an
object to a database.

I did some Google searching and didn't find anything specific to your
situation. I also didn't find anything in Microsoft's Knowledge Base
articles about this. What I did find suggests that there might be some
glitchiness with the export process using TransferDatabase, and that using
the CopyObject method (DoCmd.CopyObject) might be a better option if you
must export.

I assume that your code is running in the database that is exporting the
objects? And that that database is an .mdb file?

--

Ken Snell
<MS ACCESS MVP>

 

[Guest]

I'm open to trying what you suggest. Yes, the target database already
contained the Reports that I was exporting to it; I did not delete them in
the target database before exporting to it. The purpose in using export vs
import is that I have serveral users that have invidual copies of a program
database on their computers, and every so often there are changes to forms or
reports. It's not always the same forms or reports which need to be updated,
so I can't build the code into the users' programs to import in order to do
the update.

I tried the CopyObject. It will work if the object doesn't already exist in
the target database, but if it object is there I get a messages that the
object already exists and when I click Yes to replace, I get a run-time error
29068 (...cannot complete this operation. You must stop the code and try
again.). The report in the target database gets deleted in the process, and
when I run the code again, it will copy.

You mentioned deleting the objects from the target database first.... Any
suggestions on how I'd do this from code in the exporting database? From
what I can see it looks like the DeleteObject action only works within the
database running the code.

 

[Ken Snell [MVP]]

Perhaps the setup that you're using can be changed. Is every user using
his/her own copy of a "front end" database that is used to access the same
data in a backend database? Or are your users using completely independent,
personalized copies of the same database?


--

Ken Snell
<MS ACCESS MVP>

I'm open to trying what you suggest. Yes, the target database already
contained the Reports that I was exporting to it; I did not delete them in
the target database before exporting to it. The purpose in using export
vs
import is that I have serveral users that have invidual copies of a
program
database on their computers, and every so often there are changes to forms
or
reports. It's not always the same forms or reports which need to be
updated,
so I can't build the code into the users' programs to import in order to
do
the update.

I tried the CopyObject. It will work if the object doesn't already exist
in
the target database, but if it object is there I get a messages that the
object already exists and when I click Yes to replace, I get a run-time
error
29068 (...cannot complete this operation. You must stop the code and try
again.). The report in the target database gets deleted in the process,
and
when I run the code again, it will copy.

You mentioned deleting the objects from the target database first.... Any
suggestions on how I'd do this from code in the exporting database? From
what I can see it looks like the DeleteObject action only works within the
database running the code.

< snipped >

 

[Guest]

The users have independent, personalized copies. There are actually 2
"tools" which I try to use the Updater feature for. The first is a tool for
our off-site employees who hook up to the network to import their .csv
files/data; then they take their laptops into pharmacies and use the front
end forms to review the data against pharmacy records. The second is a tool
for our in-house employees who import separate sections of a daily report
from a centralized repository/database; then they use front end forms to
review the data and if necessary generate letters/Reports to e-fax to
pharmacies. It is these forms and reports which occasionally have changes,
either to wording or to display another field of data or add code to perform
additional functions (i.e. send summary data from the table back to a central
location for management).

I do see what you mean by glitchiness with the TransferDatabase export tho.
One minute, it's working fine replacing reports already in the database; then
2 minutes later I'm getting a 29068 and the target database becomes corrupt.
I repair the Updater database, replace the test target database, and
everything works fine again (for a short time).

 

[Ken Snell [MVP]]

Sounds as if your users are using "split" databases (data in one file, forms
and queries and reports in another, with the "front end" objects linking to
the data tables in the "back end"). If this is correct, then perhaps it
would be better if you simply provided a user with a newer version of the
front end, which the user would copy onto the old version. Much easier to
update objects that way and not have to rely on a method that you're
learning is not necessarily 100% foolproof.

Is this an option for your application?
--

Ken Snell
<MS ACCESS MVP>

 

[Guest]

Actually, it is not a "split" database. The tables/data is not linked. It
is actually imported into their copy of the database. The users just never
see their tables. It's all done through form interfaces. If I were to
provide them with a newer version of the program, they would have to make
sure their data was backed up and then import all of their data into the
newer version which can only be done if they bypass the startup since the
interfaces only allow them to import tables from a specific database based on
information selected on the forms. So when it comes down to it, there's not
much difference between that and bypassing startup to manually delete out the
forms/reports which need replacing to import the new forms/reports.

Do you know if the TransferDatabase is any more reliable in Access 2003 than
it has been in Access 2002? It worked without a problem in Access 97, but my
company is removing that application from our systems by August when they
install Office XP/Access 2003 so the conversion was necessary.