Error 2501 on import

(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.
john_priceAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ozphilCommented:
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
ozphilCommented:
Also, before reimporting modules the previous ones  have to be deleted.
0
john_priceAuthor Commented:
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
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

john_priceAuthor Commented:
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
ozphilCommented:
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
john_priceAuthor Commented:
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
ozphilCommented:
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
john_priceAuthor Commented:
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
CarmyCommented:
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
john_priceAuthor Commented:
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
z1Commented:
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
john_priceAuthor Commented:
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
z1Commented:
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
john_priceAuthor Commented:
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
z1Commented:
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
john_priceAuthor Commented:
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
ottomanCommented:
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
john_priceAuthor Commented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.