Solved

Error 2501 on import

Posted on 1997-08-15
18
644 Views
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, _
strSource,strDest

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.
0
Comment
Question by:john_price
  • 9
  • 4
  • 3
  • +2
18 Comments
 
LVL 4

Expert Comment

by:ozphil
ID: 1955647
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.


0
 
LVL 4

Expert Comment

by:ozphil
ID: 1955648
Also, before reimporting modules the previous ones  have to be deleted.
0
 

Author Comment

by:john_price
ID: 1955649
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.
0
 

Author Comment

by:john_price
ID: 1955650
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.
0
 
LVL 4

Expert Comment

by:ozphil
ID: 1955651
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?



0
 

Author Comment

by:john_price
ID: 1955652
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.
0
 
LVL 4

Expert Comment

by:ozphil
ID: 1955653
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.
0
 

Author Comment

by:john_price
ID: 1955654
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.  
0
 
LVL 1

Expert Comment

by:Carmy
ID: 1955655
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.
0
Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

 

Author Comment

by:john_price
ID: 1955656
Carmy,

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.


0
 
LVL 1

Expert Comment

by:z1
ID: 1955657
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.

z1
0
 

Author Comment

by:john_price
ID: 1955658
z1,
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
0
 
LVL 1

Expert Comment

by:z1
ID: 1955659
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.
z1
0
 

Author Comment

by:john_price
ID: 1955660
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.
0
 
LVL 1

Expert Comment

by:z1
ID: 1955661
john_price
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
0
 

Author Comment

by:john_price
ID: 1955662
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
0
 

Accepted Solution

by:
ottoman earned 200 total points
ID: 1955663
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
0
 

Author Comment

by:john_price
ID: 1955664
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.

0

Featured Post

Free Gift Card with Acronis Backup Purchase!

Backup any data in any location: local and remote systems, physical and virtual servers, private and public clouds, Macs and PCs, tablets and mobile devices, & more! For limited time only, buy any Acronis backup products and get a FREE Amazon/Best Buy gift card worth up to $200!

Join & Write a Comment

In Debugging – Part 1, you learned the basics of the debugging process. You learned how to avoid bugs, as well as how to utilize the Immediate window in the debugging process. This article takes things to the next level by showing you how you can us…
In a multiple monitor setup, if you don't want to use AutoCenter to position your popup forms, you have a problem: where will they appear?  Sometimes you may have an additional problem: where the devil did they go?  If you last had a popup form open…
Basics of query design. Shows you how to construct a simple query by adding tables, perform joins, defining output columns, perform sorting, and apply criteria.
In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now