Re: Error 3011

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

"Rob" wrote:

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!



"BeWyched" wrote:

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


"BeWyched" wrote:

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




"George Nicholson" wrote:

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,

"Rob" <Rob@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E0061D26-9DB9-4D2E-8852-C2FA0437CFD3@xxxxxxxxxxxxxxxx
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!



.

Relevant Pages

  • Re: Error 3011
    ... The forms already exist in the destination database - I believe that the ... That might make it more palatable to the ObjectType ... For Each frm in CurrentProject..AllForms ...
    (microsoft.public.access.modulesdaovba)
  • Re: Error 3011
    ... 1.That the path to the production database is incorrect or, perhaps, your ... The forms already exist in the destination database - I believe that the ... That might make it more palatable to the ObjectType ... For Each frm in CurrentProject..AllForms ...
    (microsoft.public.access.modulesdaovba)
  • Re: Error 3011
    ... Any chance someone has your Production copy open when you try to export ... if the destination database isn't open. ... ObjectType:= acForm, _ ...
    (microsoft.public.access.modulesdaovba)
  • Re: Error 3011
    ... deleting the forms before I send them (in fact, ... if the destination database isn't open. ... The forms already exist in the destination database - I believe that the ... That might make it more palatable to the ObjectType ...
    (microsoft.public.access.modulesdaovba)
  • Re: Setting up destination database using dynamic properties task/global variable
    ... Normally I need to change the database but the table name stays the same, so I just manually remove the database qualifier from the object name through Disconnected Edit, and that way I only need to manage the ... destination database server, database name, user id and password. ... added a dynamic properties task and have assigned the global variables ... Say I have created the package with destintaion as Northwind1 and I have ...
    (microsoft.public.sqlserver.dts)
Loading