Copy and overwrite objects (1 Viewer)

[JPR]

Hello,
I would appreciate any help with some code or advice on how to provide future assistance with my db.

Since I have completed the database, periodically it may happen that some office may require an update or change to a query, form, etc.
I was thinking of a way (copy object method?) that can allow me to copy the updated object directly to the other database which will still have the same name but a different path as on a different server. My db is not split as it is a small db and would like to keep it as it is.

Ex:
Updated objects ares located in a file name Updates.acccdb (located in my C drive). The updated objects would be: frm1, qry1.

The destination database is named: mydb and is located on a different server: \\S00000\Users\mydb.accdb

Thank you

 

[theDBguy]

Hi. Why not just give the user a copy of updates.accdb and tell them to put it in the same folder as the actual db?

 

[Uncle Gizmo]

Another option is to store your queries as strings in a backend table. You can then amend or replace the queries in a single location.

 

[arnelgp]

Try googling DoCmd.CopyObject, this is the path you need to thread.

 

[Micron]

My db is not split as it is a small db and would like to keep it as it is.

That's the crux of your problem. In spite of what someone may have told you, size does not matter! If you had a split db you could simply replace the fe. You can't because it contains your data too.

 

[Rene vK]

That's the crux of your problem. In spite of what someone may have told you, size does not matter! If you had a split db you could simply replace the fe. You can't because it contains your data too.

The only way to overcome your problem is move your db, do your thing an place it back... But I have to back Micron, in a situation you describe, a split must be made be & fe.

 

[JPR]

That's the crux of your problem. In spite of what someone may have told you, size does not matter! If you had a split db you could simply replace the fe. You can't because it contains your data too.

The big problem I have faced in the years with the split db is having someone on the other hand running the refresh link table manager and other simple routing maintenance tasks.

 

[Isaac]

That's the crux of your problem. In spite of what someone may have told you, size does not matter! If you had a split db you could simply replace the fe. You can't because it contains your data too.

I agree. Splitting the db is not optional, it must be done and then all the things you are encountering now can be automatically taken care of.

 

[Micron]

The big problem I have faced in the years with the split db is having someone on the other hand running the refresh link table manager and other simple routing maintenance tasks.

They should not be able to fiddle around with any of that stuff. It is up to you as a developer to prevent those things from happening. How much you have to implement depends on your users and/or your view point regarding how much control you want to exert. Users should not be able to see the nav pane. The distributed db should be an accde not an accdb. An accdr may not be good enough if users have Access because if they're savvy enough, all they have to do is change the file extension to get around that. IMO, you have not raised a valid enough point for not splitting.