We help IT Professionals succeed at work.

Error 2501 on import

john_price asked
Medium Priority
Last Modified: 2006-11-17
(MS Access 7.0)
I am trying to import objects from another database:

DoCmd.TransferDatabase acImport, "Microsoft Access", _
"c:\pieces.mdb", intType, _

All works fine for tables, queries, forms, reports and macros.  When I try to import a module, however, I get the error:

Run-time error "2501":
The TransferDatabase Action was cancelled.

Here is a pasted copy of the code causing the error:

DoCmd.TransferDatabase acImport, "Microsoft Access", _
"c:\pieces.mdb", 5, _
"GlobalStuff", "GlobalStuff"

I've tried repairing the "pieces" database, compacting it, adding other modules to "pieces" so that "GlobalStuff" is not the only one, all to no avail.
Watch Question

Try importing the modules manually one at a time until you get an error which indicates you have a duplicate global variable or function already in the database or one of the libraries.

Modify the modules in source or target so that no conflict occurs.

I shall look further into this with a mockup.

Also, before reimporting modules the previous ones  have to be deleted.


Sounds like you may be able to provide the answer, but not yet.  I have only ONE module being imported.  It is the one causing the error.


I have already tried importing the single module manually, and it comes in with no problems.  The macro action transferdatabase also works ok.  The error only occurs when I do it from code with the transferdatabase method.  The work-around I thought of did not work:  use the runmacro method to run a transferdatabase macro.  It still gives the cancelled error.  Also, I need to be able to set the module name at run time.

Thanks john_price.

Frustrating no doubt. I tried importing from code and it works ok, so i havnt been able to reproduce your error when everything is correct.

I used docmd transferdatabase etc rather than docmd.transferdatabase method. would this by any chance do it?


Not sure I follow your comment:  "I used docmd transferdatabase etc rather than docmd.transferdatabase method"

All works fine if I use the transferdatabase action in a macro.  The problem only occurs on the docmd.transferdatabase method in code.  I need the flexiblity of the code method, however.

I created a macro which successfully uses the transferdatabase action when run from the macro tab.  Then I tried to "runmaco" it from code.  It faile with the same error.

I meant that I used Docmd Transferdatabase .... in Access Basic code rather than Docmd.Transferdatabase syntax. This was the Access 2 syntax. Try it see if it works.


I don't understand what you mean.  I've been using VBA all along.  Your last comment seems to indicate that you simply drop the period from the syntax, separating it as a method from docmd.  I couldn't find any reference to this type of use, nor would it compile.  

I had a similar problem that was solved when I changed some of the Functions/Subs names;
What I think you should try is to create a dummy Module with one or two functions with names you are sure do not exist in any other library or wizard etc. Try to import that Module. (There should be no other modules in the database)
If this module is not rejected (as the one you have problems with),  then you need to rename your functions/subs  and ANY GLOBAL CONST\VARIABLES in GlobalStuff.
If the dummy module is rejected, then your problem is NOT the module but the actual Access setup.



Thanks for the response.
Following your suggestion, I created the following module in the source database.
-------------------- Module1 --------------------
Option Compare Database
Option Explicit

Private intJunkfortesting As Integer
Private strJunkfortesting As String
Private Sub junkytesting1()

End Sub
Private Sub junkytexting2()

End Sub
---------------------- End Module1 -------------

---------------------- Code statement which is  failing ------
        DoCmd.TransferDatabase acImport, "Microsoft Access", _
        strDatabaseName, intObjectType, _
        strObjectName, strObjectName, True
---------------------- End code statement ------------------

The above is being done within a loop which is reading the strObjectName and intObjectType from a recordset built from the source database.  All object types import properly through this statement except modules.  I have varified that when the program halted on the "2501", that strObjectName was "Module1" and that intObjectType was 5.

I tried this same thing on another computer where it is unlikely that the SAME Access setup problem would exist.


You have to re-create the source database from scratch.
Follow this procedure:
1) create new empty database
2) manually import all objects from old source database
3) replace source database with the new one.

Now your code will work.
Be sure you are NOT using /Runtime switch when running Microsoft Access 7.0 if you need do import/export from code. You will have to upgrade to Access 97 if you need this switch functionality in this case.

This unusual problem is related to MS Access 7.0 bug.

Hope this helps.



Sorry, no go.  I am using "createdatabase" to create the database in the first place.  This is done in the same procedure as the export of the module, and works well.  I can't require the end user to intervene manually.  This is being done to provide "software upgrades" to end users.

When I run another procedure which tries to import that object, I get the error.  (The object does not yet exist in the running database at this point, or has just been deleted.)

However, I did try your suggestion to try to verify that this really is the cause.  Perhaps then a work-around could be delveloped.  I used my "createdatabase" procedure to create the database "pieces.mdb".  I then created a new, empty database from Access 7 and imported all the objects from pieces.mdb, including the module.  I then deleted pieces.mdb, and renamed my new database to that name.  I got the same error (#2501) on trying to do the import programmatically.

I can sneak code into the end user's program if I make it part of a form module, but not as a code module.  

-- John

So I can only point you M$ Knowledge Base article describing error like this one.
Article ID is Q158923, title: TransferDatabase/CopyObject in Runtime May Corrupt Object.
This might help you to track down the problem.
I'm afraid that kind of error is in source database, not in import procedure.


I'll check out the article.  I agree that the problem may be in the source database, but I'm also concerned that there is an engine feature being invoked only when run from code which may be contributing.  I'll let you know if the article contains the key.

You might want to clarify 2 things:
1) are you using run-time version of MS Access 7.0, or /Runtime parameter;
2) is your result database a source database for next update?
If answer to both question is YES, you might only complain to M$.
Regards - z1


z1,  Thanks.  1) No, it is not the runtime or with a /runtime parm,  and 2) my receiving (result) database does not ever export a module.  I have a database, "master.mdb", which exports objects to "pieces.mdb".  The end user, running "slave.mdb" imports those objects from "pieces.mdb".  This is how we are providing software upgrades to the end user installations.

I've checked the article, and though related, it does not seem to apply.  I've left this same message on the msdn.  In the meantime, I guess I'll have to "sneak" my code into the slave.mdb by putting into forms.

-- John
You can not have code in your databases to import modules from other databases into it. In order to accomplish this task do the following.

.)Create a new database with the extension *.MDA (i.e. a library)
.)Shift your module importing code into this library
.)Rewrite your code, so it imports the module not into the library database but into the target database
.)Register the librar (add the necessary lines to Access.INI)
.)Open the target database and make a call to the importing routine of the library database

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


This is pretty much what I found out from MS.  Here's hoping this is fixed someday.  Is it fixed in Access 8?

Anyway, I like the idea of registering a library with the transfer code in it.  Thanks to everyone who helped.

Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.