Error 3011

[Guest]

I posted this question a week or so ago and got no response. I hope the
repost doesn't bother anyone...

We have an Access 2003 db on a shared drive in our network, and I have a
development copy on my own system. I'd like to write a bit of code to export
all the forms on the development copy to the production copy. Thus:

Sub ExportForms()

Dim frm as AccessObject

For Each frm in CurrentProject..AllForms
DoCmd.TransferDatabase TransferType:= acExport, _
DatabaseType:= "Microsoft
Access", _
DatabaseName:=
"X:\mypath\myDB.mdb", _
ObjectType:= acForm, _
Source:= frm.Name, _
Destination:= frm.Name
Next frm

End Sub

However, when I run the code it returns an error 3011, telling me that the
Microsoft Jet Database could not find the object "Databases". I'm not sure
what this means, since I am not referring to any object called "Databases".
Any ideas?

Thanks!

 

[George Nicholson]

Not sure, but you might try changing your declaration of frm from
AccessObject to Form. That might make it more palatable to the ObjectType
(i.e., acForm) argument.

HTH,

 

[Guest]

Hi Rob

Your code is perfectly OK (other than a double '..' in
CurrentProject..AllForms which I assume is a typo - it must be a single .) -
I've copied it into my PC and it works without any errors.

The only explanations I can think of are:

1.That the path to the production database is incorrect or, perhaps, your
local machine isn't mapped to the 'X' drive.
2. The forms already exist in the destination database - I believe that the
TransferDatabase method will throw an error if a form with the same name
already exists in the destination. If so, then you could try
deleting/renaming the existing destination forms and see if it works. If so,
write code to delete the forms prior to the transfer.

Good luck.

BW

 

[Guest]

Sorry Rob - my info. isn't quite correct - forms can be overwritten but only
if the destination database isn't open. If it is open then the coding will
throw an error.

BW

 

[Guest]

Thanks, BW. I have tried various things towards this end: I used the
absolute path to the network drive ("\\Public\Data\etc"), and I've tried
deleting the forms before I send them (in fact, sending them to a fresh
database instead). No soap. :-(

You are correct, BTW, the double-dot was a typo!

 

[Guest]

Sorry it didn't work.

The only other things I can think of/suggest are:

1. Is the Destination database the same version as the source. If not then
perhaps the new forms are not compatible with the destination DB?
2. Have you tried the action to a new destination located on the development
PC. This will show whether its a coding/Access issue, or a network problem.
3. Have you tried disabling any firewalls. It could be that 'external'
attempts to amend local files are seen as potentially malicious.
4. I've found the following article on the MS Knowledge Base. It refers to
v.old versions but may still be relevant as it does mention the error message
you get:
http://support.microsoft.com/kb/121646/en-us

Don't give up!!

BW

 

[George Nicholson]

Any chance someone has your Production copy open when you try to export
forms to it? Access (since 97) doesn't allow design changes unless the file
is open exclusively, so that could be preventing TransferDatabase from
working. (This is just a guess...)

If all else fails, you might try turning the process around and see if it
works better: import forms from Development to Production.

HTH,

 

[Guest]

Rob,

Just a thought - have you considered splitting your database? I assume the
reason you're just exporting the forms to the production system is because
you don't want to overwrite the production data. Split your database into
two, one "back end" containing just the data, the other "front end"
containing all the forms (and queries, reports and modules), with the tables
from the back end linked into the front end. Then when you want to issue a
new version you just completely overwrite the production front end with a new
one.

Generally, when I'm developing I link my development front end to a local
copy of the back end. This makes things run a little quicker and also means I
don't mess up live data when I'm testing. The only thing to watch for though
is that you don't forget to re-link the tables to the live back end before
you release the new version, and then link them back to the local copy again
before you do more development.

Regards,

Jon.