S
Stapes
Set fileObj = CreateObject("scripting.filesystemobject")
fileObj.CopyFile strBackEndName, strBackupName, True
Stapes
fileObj.CopyFile strBackEndName, strBackupName, True
Stapes
D
Douglas J. Steele
That sets a reference to FSO (File System Object), which is part of VB
Scripting. It then uses FSO's CopyFile method to make a copy of the file.
Now, since I was reading another thread you have going, I'm guessing you
want to use this because it doesn't give you the "File In Use" error you're
getting through other methods. Be aware that just because FSO's CopyFile
method will copy a file that's in use, that doesn't mean it's a good idea to
do so. That's especially true with Access databases: it's entirely possible
that the copy will be in an inconsistent state because Access was doing
something to the file when the copy took place. In other words, your backup
copy may be incomplete, so that relying on it would be a bad idea.
Scripting. It then uses FSO's CopyFile method to make a copy of the file.
Now, since I was reading another thread you have going, I'm guessing you
want to use this because it doesn't give you the "File In Use" error you're
getting through other methods. Be aware that just because FSO's CopyFile
method will copy a file that's in use, that doesn't mean it's a good idea to
do so. That's especially true with Access databases: it's entirely possible
that the copy will be in an inconsistent state because Access was doing
something to the file when the copy took place. In other words, your backup
copy may be incomplete, so that relying on it would be a bad idea.
S
Stapes
So is this routine any safer:
Declare Function CopyFile& Lib "kernel32" Alias "CopyFileA" (ByVal _
lpExistingFilename As String, ByVal lbNewFileName As String, ByVal _
bFailIfExists As Long)
Public Sub MakeFileCopy(strExistingFile As String, _
strNewfile As String, _
blnDoNotOverWrite As Boolean)
Dim strMessage As String
strExistingFile = strExistingFile
strNewfile = strNewfile
If CopyFile(strExistingFile, strNewfile, blnDoNotOverWrite) = 1
Then
strMessage = "File successfully copied."
Else
strMessage = "File copy failed."
End If
MsgBox strMessage, vbInformation, "Copy File"
End Sub
D
Douglas J. Steele
Stapes said:
Yes, much.
A
aaron.kempf
Do you serisouly believe that?
Do you have any references for that claim?
How is it safer? Have you seen this in writing? Have you tested the
components personally?
I'm not trying to be difficult; I just don't believe everything that I
read online.
I've been using FSO 10 times a day for the past decade and never had
any problem with FSO.
Furthermore; I believe that FSO objects are easier to rewrite
into .NET so I believe it is a 'best practice' to use FSO.
Thanks
-Aaron
Do you have any references for that claim?
How is it safer? Have you seen this in writing? Have you tested the
components personally?
I'm not trying to be difficult; I just don't believe everything that I
read online.
I've been using FSO 10 times a day for the past decade and never had
any problem with FSO.
Furthermore; I believe that FSO objects are easier to rewrite
into .NET so I believe it is a 'best practice' to use FSO.
Thanks
-Aaron
D
Douglas J. Steele
Did you bother to read the explanation I gave?
"just because FSO's CopyFile method will copy a file that's in use, that
doesn't mean it's a good idea to do so. That's especially true with Access
databases: it's entirely possible that the copy will be in an inconsistent
state because Access was doing something to the file when the copy took
place. In other words, your backup copy may be incomplete, so that relying
on it would be a bad idea."
You should know that Access buffers much of its activity, so that it can
take a measurable amount of time for a write to actually be completed.
Unfortunately, since it's a timing-related thing, there's no way to create a
test that's guaranteed to prove that it's not a good idea, but I'm not
willing to take the chance that the MDB file will be in a steady state when
the copy takes place.
There's a reason why the other methods refuse to do the copy!
--
Doug Steele, Microsoft Access MVP
(no private e-mails, please)
Do you serisouly believe that?
Do you have any references for that claim?
How is it safer? Have you seen this in writing? Have you tested the
components personally?
I'm not trying to be difficult; I just don't believe everything that I
read online.
I've been using FSO 10 times a day for the past decade and never had
any problem with FSO.
Furthermore; I believe that FSO objects are easier to rewrite
into .NET so I believe it is a 'best practice' to use FSO.
Thanks
-Aaron
"just because FSO's CopyFile method will copy a file that's in use, that
doesn't mean it's a good idea to do so. That's especially true with Access
databases: it's entirely possible that the copy will be in an inconsistent
state because Access was doing something to the file when the copy took
place. In other words, your backup copy may be incomplete, so that relying
on it would be a bad idea."
You should know that Access buffers much of its activity, so that it can
take a measurable amount of time for a write to actually be completed.
Unfortunately, since it's a timing-related thing, there's no way to create a
test that's guaranteed to prove that it's not a good idea, but I'm not
willing to take the chance that the MDB file will be in a steady state when
the copy takes place.
There's a reason why the other methods refuse to do the copy!
--
Doug Steele, Microsoft Access MVP
(no private e-mails, please)
Do you serisouly believe that?
Do you have any references for that claim?
How is it safer? Have you seen this in writing? Have you tested the
components personally?
I'm not trying to be difficult; I just don't believe everything that I
read online.
I've been using FSO 10 times a day for the past decade and never had
any problem with FSO.
Furthermore; I believe that FSO objects are easier to rewrite
into .NET so I believe it is a 'best practice' to use FSO.
Thanks
-Aaron
A
aaron.kempf
I just don't get it.
You are claiming the API call is _SAFER_ than the Fso CopyFile-- why
is this?
It seems to me like it's a problem with MDB not with FSO / WSH.
I use FSO / WSH every day and I have for a decade. It is by far my
2nd favorite library (next to ADO).
I just don't get _WHY_ you can blame it on Fso.CopyFile when it seems
to me like it's a bug in MDB.
Does the API call do something like 'wait until a file isn't being
used'?
I'm just trying to stick to the facts here, thanks.
-Aaron
You are claiming the API call is _SAFER_ than the Fso CopyFile-- why
is this?
It seems to me like it's a problem with MDB not with FSO / WSH.
I use FSO / WSH every day and I have for a decade. It is by far my
2nd favorite library (next to ADO).
I just don't get _WHY_ you can blame it on Fso.CopyFile when it seems
to me like it's a bug in MDB.
Does the API call do something like 'wait until a file isn't being
used'?
I'm just trying to stick to the facts here, thanks.
-Aaron
A
aaron.kempf
I just don't get why you're blaming this MDB bug on FSO.
-Aaron
-Aaron
D
Douglas J. Steele
To be honest, I wasn't saying that the API call was better because it was an
API call. I said it was safer because it won't work if the file is in use.
The VBA FileCopy statement is just as safe, for the same reason.
It's not a bug in MDBs. If you were in the midst of using Word, and someone
copied your .DOC (or .DOCX) file, you'd have the same issue: you couldn't be
sure that the backup was 100% accurate. Same thing with any other file type.
SQL Server, and other server-based DBMS, don't have this issue because they
correctly log all the work that's been done. That's just not reasonable to
expect with any file-based system.
API call. I said it was safer because it won't work if the file is in use.
The VBA FileCopy statement is just as safe, for the same reason.
It's not a bug in MDBs. If you were in the midst of using Word, and someone
copied your .DOC (or .DOCX) file, you'd have the same issue: you couldn't be
sure that the backup was 100% accurate. Same thing with any other file type.
SQL Server, and other server-based DBMS, don't have this issue because they
correctly log all the work that's been done. That's just not reasonable to
expect with any file-based system.
A
aaron.kempf
Ok.. perfect. I didn't catch that earlier; I'm sorry for giving you a
hard time.
I just had never heard this about the API before- -it's interesting to
me. I've got considerable code to do the same thing all over the
place; I'll have to re-examing my CopyFile procedures; thanks!
PS - FileBased systems I've used = AS 400, bTrieve, Access, even mySql
is a quasi-file based system (even though it has a real relational
engine). I believe that AS 400 and mySql properly log; I don't know
about bTrieve.. I think that it supported transactions at least.
Well I believe that a couple of the architectures for mySql supports
logging at least.
I actually _REALLY_ like some file based systems. I think that having
a seperate file for each table is a no-brainer.. I wish it was an
option on every database (server). I mean it helps recovery a _LOT_
when you can force out the (clean) data if and when you have trouble.
I was actually retiring the btrieve system.. Never got around to
checking out logging on it
I moved client to SharePoint.. via Access of course.. I had _SUCH_ a
hard time moving this one table to SharePoint.. it was like 17k
records. Finally someone came over and showed me the same (insert
17k records into SP) using Excel. It worked instantly. So it's
obvious that SharePoint lived with that many records-- but the Access
implementation of SharePoint just puked when it hit that many
records. It's always amazed me-- if Microsoft screwed up SharePoint
- Access so bad in Access 2003 version; why is it that it became the
center of Microsoft strategy for Access 2007?
I love SharePoint. I just wish that it worked with a larger number of
records and it had enterprise level ETL tools; in a similiar fashion
to DTS / SSIS... but _GUI_ and support Macros and .NET.
I think that 'dumbing down SQL Server to SharePoint' really helps
people get off the heroin (MDB).. so I love SharePoint.
That would really rock-- to turn SharePoint into a full fledged
database eco-system. As it is; everywhere i've ever been-- people
refused to edit the SQL Store for SharePoint directly.. Which means we
couldn't bulk insert 17k records the logical way- into the SQL table
directly.
I just don't like the idea of a system that doesn't have real ETL
tools in it. That's the thing holding me back from sleeping with
SharePoint (more).
-Aaron
hard time.
I just had never heard this about the API before- -it's interesting to
me. I've got considerable code to do the same thing all over the
place; I'll have to re-examing my CopyFile procedures; thanks!
PS - FileBased systems I've used = AS 400, bTrieve, Access, even mySql
is a quasi-file based system (even though it has a real relational
engine). I believe that AS 400 and mySql properly log; I don't know
about bTrieve.. I think that it supported transactions at least.
Well I believe that a couple of the architectures for mySql supports
logging at least.
I actually _REALLY_ like some file based systems. I think that having
a seperate file for each table is a no-brainer.. I wish it was an
option on every database (server). I mean it helps recovery a _LOT_
when you can force out the (clean) data if and when you have trouble.
I was actually retiring the btrieve system.. Never got around to
checking out logging on it
I moved client to SharePoint.. via Access of course.. I had _SUCH_ a
hard time moving this one table to SharePoint.. it was like 17k
records. Finally someone came over and showed me the same (insert
17k records into SP) using Excel. It worked instantly. So it's
obvious that SharePoint lived with that many records-- but the Access
implementation of SharePoint just puked when it hit that many
records. It's always amazed me-- if Microsoft screwed up SharePoint
- Access so bad in Access 2003 version; why is it that it became the
center of Microsoft strategy for Access 2007?
I love SharePoint. I just wish that it worked with a larger number of
records and it had enterprise level ETL tools; in a similiar fashion
to DTS / SSIS... but _GUI_ and support Macros and .NET.
I think that 'dumbing down SQL Server to SharePoint' really helps
people get off the heroin (MDB).. so I love SharePoint.
That would really rock-- to turn SharePoint into a full fledged
database eco-system. As it is; everywhere i've ever been-- people
refused to edit the SQL Store for SharePoint directly.. Which means we
couldn't bulk insert 17k records the logical way- into the SQL table
directly.
I just don't like the idea of a system that doesn't have real ETL
tools in it. That's the thing holding me back from sleeping with
SharePoint (more).
-Aaron