Backup

[sergran]

Hello, thank you for the code .. the problem, and that in this way I export the entire table in another database while I serve it to be exported only one record in another table and that the table or the database using the ID name that identifies the record

[June7]

What I posted is an example, adapt it to your situation. My code exports queries, not tables. If you want a limited set of records to be exported, then build the query to retrieve them. Could probably even be a subquery in the SELECT INTO statement, something like:

CurrentDb.Execute "SELECT * INTO tablename IN '" & strExtract & "' FROM (SELECT * FROM tablename WHERE fieldname='something') As Query1;"

[sergran]

Hello, I'm sorry but I can not understand how I use your suggestion

CurrentDb.Execute "SELECT * INTO tablename IN '" & strExtract & "' FROM (SELECT * FROM tablename WHERE fieldname = 'something') As Query1;"

I tried to put it in a sql query as a code but does not work. Could you kindly send me a sample mdb?
Thanks and sorry

[June7]

I don't have a sample database and the working db that my code is from is far too complex and large and I am not going to build one just for this thread.

The example provided post 15 is adequate to follow in writing code for your situation. If you don't know VBA well enough, then the first requirement is to learn VBA.

[stmoong]

Ok, maybe this may not answer your question directly.

Instead of writing records to another database each time there is a change, you could consider writing a simple vb script and create copies of the database files (probably date or time stamp) and set it to run as a scheduled task.

The script needs to check if the database file is in use or not. You could set it to run when no one is in office, for example, during midnight or lunch time (just make sure the user disconnect).

If the application is critical and downtime is a concern, then you should consider migrating it to other databases like MS SQL or Oracle that have more advanced backup facilities (e.g. mirroring, etc).

If you are still going ahead to implement the way you proposed (i.e. updating records into another database), then, you need to take care of transactions, otherwise, you might end up having the two databases that are not synchonized.

I hoped I did not misunderstand what you were trying to do.