Making a copy of the current database using code

[Janelle.Dunlap]

In the database that I am creating I need to be able to rename the file
with a name that the user specifies using the Save As Dialog window (I
already have the code that brings up this window). In other words, I
need to write code that makes a copy of the current database and saves
it with a new name. I've read that it is a bad idea to copy a file
that is currently in use so I am at a loss of what I should do. Any
suggestions?

[Ron2006]

We cannot tell from what you have told us, However,

Is this a split application (ie. BE and FE)

Are you trying to backup the data or the forms?

If it is a FE and BE, renaming the BE will destroy the links, You would
have to copy it and rename the copy. Also it will probably NOT allow
you to rename the mdb you are in anyway. Usually it will allow a copy
but not a rename. Consequently SaveAs is probably not the way to go
since it says you have to have the mdb open and if it is the FE that
you are saving as it does nothing about the data.

Copy of the BE runs the risk of copying right in the middle of an
update so that at least the copy may be corruped. The only way to
forstall that is that everyone would have to be out of the BE when it
was done.

[Janelle.Dunlap]

Thanks for the reply. It is not a backup that I am trying to create,
it will will eventually become a seperate database that users will
access. The purpose of my database is somewhat complex...I am creating
a database that provides a simple and easy way for people to load their
data into it and actually create a new database for them (all for the
same purpose mind you, but different data). I thought the best way to
go about this was to have them load the data required into this main
database and then copy the database with a new name. I originally
planned to have a blank database open and just export the data into it
but I thought this would be an easier solution. Probably not though.

[Ron2006]

Ja************@ge.com wrote:

Thanks for the reply. It is not a backup that I am trying to create,
it will will eventually become a seperate database that users will
access. The purpose of my database is somewhat complex...I am creating
a database that provides a simple and easy way for people to load their
data into it and actually create a new database for them (all for the
same purpose mind you, but different data). I thought the best way to
go about this was to have them load the data required into this main
database and then copy the database with a new name. I originally
planned to have a blank database open and just export the data into it
but I thought this would be an easier solution. Probably not though.

Sorry for the new topic line. It won't let me respond normally.

You still haven't told us if this is a BE/FE situation, because that
will determine the type of response we can offer, and allow us to
indicate pitfalls to watch for.

[Rick Wannall]

Study up on Replication/Synchronization. If you want to make multiple
copies, and allow users to enter data into the different copies, and
integrate all that back into a master somewhere, this is the way to do it.
If you synchronize all of them over time you wind up with all the data in
all the copies. If you get data from one copy back into the master and
you're finished with the copy for good, you can just delete it. Access
master doesn't care about whether any of the copies still exist or not.

It's very easy to set up.

[David W. Fenton]

"Rick Wannall" <wa*****@sbcglobal.net> wrote in
news:mN*******************@newssvr11.news.prodigy. com:

Study up on Replication/Synchronization. . . .
No, this really has nothing to do with the question being asked.
. . . If you want to make multiple
copies, and allow users to enter data into the different copies,
and integrate all that back into a master somewhere, this is the
way to do it.
Assuming you have a split architecture where you're replicating only
the data, that's one solution to the problem you describe, but it
only works if the individual users can connect to a common network,
or a chain of networks (A->B->C->B->A, where C does not have to be
able to connect directly to A, but there has to be a path from C to
A through an intervening network connection).
If you synchronize all of them over time you wind up with all the
data in all the copies. If you get data from one copy back into
the master and you're finished with the copy for good, you can
just delete it.
This is just so much complete bullshit. Access/Jet *does* care if
you delete the source replica, as it has a record of it.
. . . Access
master doesn't care about whether any of the copies still exist or
not.
Yes, Jet *does* care. Any replica that participates in a synch is
then known to every other replica and the list of replicas is
maintained in perpetuity until you delete the replica from the
replica set (something that can only be done by attempting a synch
with the deleted replica, which means the network path has to be
accessible). Deleting replicas can lead to data errors, data
corruption and eventual loss of the entire replica set. At the very
least, once it develops, you can't say for certain whether or not
the synched replicas are actually identical or not, so the data
might as well be corrupted, since it's no longer reliable.
It's very easy to set up.

And you are clearly a moron who knows absolutely nothing about
actually using Jet replication over the long term.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Rick Wannall]

Sorry, we just haven't had the kind of difficulties using it that you seem
to experience.

OP: If you set this up properly, it works great.

[Janelle.Dunlap]

Thanks all for responding. I don't think that synchronization is
necessary in what I am trying to do mainly because the data does not
need to be integrated back to the master. Each database that is
created from the master will be a stand alone environment so my main
problem is in creating the copy of the database. Right now I am
creating a split database (with both a FE and BE) that needs to be
copied and turned into a seperate database or be able to
programatically export the data that the user enters into the master
into a blank database that the user names. The more I think about it
the more the latter makes more sense.

[David W. Fenton]

"Rick Wannall" <wa*****@notadomain.de> wrote in
news:tw*******************@newssvr11.news.prodigy. com:

Sorry, we just haven't had the kind of difficulties using it that
you seem to experience.
The difficulties will happen to anyone who deletes replicas in the
file system without deleting them from the replica set.

Your replica set is unreliable, as you can't say if the data is
actually synching completely.
OP: If you set this up properly, it works great.

You're lying. You would have had the problems if you had done what
you are recommending.

I've been doing Jet replication since 1997 and I've seen it all. If
you actually were doing what you've recommended, then your replica
set would be corrupted, whether you know that fact or not.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

Ja************@ge.com wrote:

I need to write code that makes a copy of the current database and saves
it with a new name.

Air Code:

Public Sub CopyMe(ByVal NewMe As String)
Dim o As AccessObject
SaveAsText 6, "", NewMe
With CurrentProject
For Each o In .AllForms
With o
DoCmd.CopyObject NewMe, .Name, acForm, .Name
End With
Next o
For Each o In .AllMacros
With o
DoCmd.CopyObject NewMe, .Name, acMacro, .Name
End With
Next o
For Each o In .AllModules
With o
DoCmd.CopyObject NewMe, .Name, acModule, .Name
End With
Next o
For Each o In .AllReports
With o
DoCmd.CopyObject NewMe, .Name, acReport, .Name
End With
Next o
End With
For Each o In CurrentData.AllQueries
With o
DoCmd.CopyObject NewMe, .Name, acQuery, .Name
End With
Next o
End Sub

Sub test()
CopyMe "temp.mdb"
End Sub

[Ron2006]

Keep in mind that if you are trying to make a copy of a BE-FE set, you
will ALSO have to change all of the linked references in the copied FE
to now point to the newly created BE.

If you don't do that then allyou have done is create a backup of the BE
and another FE pointing to your current BE and not the new BE.