Getting run-time 3009 error on "DoCmd.TransferDatabase acExport" statement

[ncsthbell]

I am using MS2007 on windows XP. I support an access application which has a 'main menu' (form) and on this form there is a button 'Exit Database'. In the 'on click' event code for the 'Exit Database' button the following is code is executed to copy a table to another database:

DoCmd.TransferDatabase acExport, "Microsoft Access", "C:\Inv\ITH.mdb", acTable, "HWI", "HWI"
 

This produces the run-time 3009 error which states "You tried to lock table "HWI" while opening it, but the table cannot be locked because it is currently in use."

There is no code on this 'form_load' event on this form that references this table, there is no recordsource defined on the data property for this form. I see no where that this table is referenced or open at this point.

I have opened this application without selecting any other buttons on the main menu form and click on the 'exit database' button to try to make sure I have not opened the referenced table. I still get the error.

The users informed me that this has been happening since we upgraded to MS2007, they just have not mentioned it.
I don't understand why access thinks there the table is in use. Not sure what in 2007 could have made this not work. We were on MS2000 prior and this worked fine.

I am out of ideas. Any suggestions would be greatly appreciated!!

[NeoPa]

Are any of the references to tables in the active database?

What are the Lock settings in your installation of Access?

PS. For ease of understanding the question I'm reposting your code more clearly :

Call DoCmd.TransferDatabase(TransferType:=acExport, _
                            DatabaseType:="Microsoft Access", _
                            DatabaseName:="C:\Inv\ITH.mdb", _
                            ObjectType:=acTable, _
                            Source:="HWI", _
                            Destination:="HWI")

[ncsthbell]

There are references to the tables in the active database, however, when I open the main menu and click on the exit button, the table has not been opened.
I will have to check with our tech support group to find out what the lock options are set to on the installation.
I found out that the reason the person that wrote this is doing these exports is to update a 'read' only version of this same database. So, what they have is the same database duplicated in another location and when a user goes into the 'write' version and make changes, upon exiting, the tables are exported to the 'read' version. Now I am thinking this is absurd! There should not be 2 versions just for read and write. I am thinking to scrap worrying about getting these exports to work and to build a user table. I can check when they login and determine how to set the form properties for the 'read only' users. This would eliminate having 2 copies of the same database just for read or write access. I just love these inherited databases!

[NeoPa]

ncsthbell:
I just love these inherited databases!

They are always the most fun huh. When you manage to determine what someone has been thinking behind some of the weird things they do. I actually find myself having the same thoughts about some of my own older databases sometimes too. That's frightening!

[ncsthbell]

Nice to know I am not the only one that deals with these older databases. In our case, we had users that were allowed to create any access database they wanted. Then, with MS2007, they were given 'runtime' only access. Given that, the IT dept. inherited all of these databases to support. It has been a nightmare! Slowly, one by one I am figuring them out!