|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
Hello,
In a VBA module, how can I tell if a file exists before doing the TransferSpreadsheet? What I would like is something like this:
filename = <calculated from some values on the form> if filename exists then ask for alternate file name endif
Thank you,
Brenda
|
|
Try something like this.
Function ReportFileStatus(filespec) Dim fso, msg Set fso = CreateObject("Scripting.FileSystemObject") If (fso.FileExists(filespec)) Then msg = "File exists." Else msg = "File doesn't exist." End If ReportFileStatus = msg Set fso = Nothing End Function
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Brenda" wrote: | Hello, | | In a VBA module, how can I tell if a file exists before doing the | TransferSpreadsheet? What I would like is something like this: | | filename = <calculated from some values on the form> | if filename exists then | ask for alternate file name | endif | | | Thank you, | | Brenda | |
|
|
Thank you!
....Brenda
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:eyIBUrMQGHA.4900[ at ]TK2MSFTNGP09.phx.gbl...
[Quoted Text] > Try something like this. > > Function ReportFileStatus(filespec) > Dim fso, msg > Set fso = CreateObject("Scripting.FileSystemObject") > If (fso.FileExists(filespec)) Then > msg = "File exists." > Else > msg = "File doesn't exist." > End If > ReportFileStatus = msg > Set fso = Nothing > End Function > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> > "Brenda" wrote: > | Hello, > | > | In a VBA module, how can I tell if a file exists before doing the > | TransferSpreadsheet? What I would like is something like this: > | > | filename = <calculated from some values on the form> > | if filename exists then > | ask for alternate file name > | endif > | > | > | Thank you, > | > | Brenda > | > | > >
|
|
That's really overkill, introducing the overhead of FSO just to check for file existence.
Function ReportFileStatus(FileSpec As String) As String Dim strMsg As String
If Len(Dir(FileSpec)) > 0 Then strMsg = "File exists." Else strMsg = "File doesn't exist." End If ReportFileStatus = strMsg
End Function
-- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!)
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:eyIBUrMQGHA.4900[ at ]TK2MSFTNGP09.phx.gbl...
[Quoted Text] > Try something like this. > > Function ReportFileStatus(filespec) > Dim fso, msg > Set fso = CreateObject("Scripting.FileSystemObject") > If (fso.FileExists(filespec)) Then > msg = "File exists." > Else > msg = "File doesn't exist." > End If > ReportFileStatus = msg > Set fso = Nothing > End Function > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> > "Brenda" wrote: > | Hello, > | > | In a VBA module, how can I tell if a file exists before doing the > | TransferSpreadsheet? What I would like is something like this: > | > | filename = <calculated from some values on the form> > | if filename exists then > | ask for alternate file name > | endif > | > | > | Thank you, > | > | Brenda > | > | > >
|
|
You're welcome.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Brenda" wrote: | Thank you! | | ...Brenda
|
|
I timed both in the case the file exists and when the file doesn't exist and can't really determine one is faster than the other. As far as overhead FSO is destroyed immediately after use so I don't really see any overhead.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Douglas J Steele" <NOSPAM_djsteele[ at ]NOSPAM_canada.com> wrote in message news:uRZKv%23RQGHA.3460[ at ]TK2MSFTNGP15.phx.gbl... | That's really overkill, introducing the overhead of FSO just to check for | file existence. | | Function ReportFileStatus(FileSpec As String) As String | Dim strMsg As String | | If Len(Dir(FileSpec)) > 0 Then | strMsg = "File exists." | Else | strMsg = "File doesn't exist." | End If | ReportFileStatus = strMsg | | End Function | | | -- | Doug Steele, Microsoft Access MVP | http://I.Am/DougSteele | (no e-mails, please!) | | | "Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message | news:eyIBUrMQGHA.4900[ at ]TK2MSFTNGP09.phx.gbl... | > Try something like this. | > | > Function ReportFileStatus(filespec) | > Dim fso, msg | > Set fso = CreateObject("Scripting.FileSystemObject") | > If (fso.FileExists(filespec)) Then | > msg = "File exists." | > Else | > msg = "File doesn't exist." | > End If | > ReportFileStatus = msg | > Set fso = Nothing | > End Function | > | > -- | > | > Regards, | > | > Dave Patrick ....Please no email replies - reply in newsgroup. | > Microsoft Certified Professional | > Microsoft MVP [Windows] | > http://www.microsoft.com/protect | > | > "Brenda" wrote: | > | Hello, | > | | > | In a VBA module, how can I tell if a file exists before doing the | > | TransferSpreadsheet? What I would like is something like this: | > | | > | filename = <calculated from some values on the form> | > | if filename exists then | > | ask for alternate file name | > | endif | > | | > | | > | Thank you, | > | | > | Brenda | > | | > | | > | > | |
|
|
Any time you introduce an additional COM library, there's overhead. It may not add an appreciable amount of time, but it's definitely there, and is just one more thing that can go wrong.
-- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!)
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:OFacG3SQGHA.3896[ at ]TK2MSFTNGP15.phx.gbl...
[Quoted Text] > I timed both in the case the file exists and when the file doesn't exist
and > can't really determine one is faster than the other. As far as overhead FSO > is destroyed immediately after use so I don't really see any overhead. > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect > > "Douglas J Steele" <NOSPAM_djsteele[ at ]NOSPAM_canada.com> wrote in message > news:uRZKv%23RQGHA.3460[ at ]TK2MSFTNGP15.phx.gbl... > | That's really overkill, introducing the overhead of FSO just to check for > | file existence. > | > | Function ReportFileStatus(FileSpec As String) As String > | Dim strMsg As String > | > | If Len(Dir(FileSpec)) > 0 Then > | strMsg = "File exists." > | Else > | strMsg = "File doesn't exist." > | End If > | ReportFileStatus = strMsg > | > | End Function > | > | > | -- > | Doug Steele, Microsoft Access MVP > | http://I.Am/DougSteele > | (no e-mails, please!) > | > | > | "Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message > | news:eyIBUrMQGHA.4900[ at ]TK2MSFTNGP09.phx.gbl... > | > Try something like this. > | > > | > Function ReportFileStatus(filespec) > | > Dim fso, msg > | > Set fso = CreateObject("Scripting.FileSystemObject") > | > If (fso.FileExists(filespec)) Then > | > msg = "File exists." > | > Else > | > msg = "File doesn't exist." > | > End If > | > ReportFileStatus = msg > | > Set fso = Nothing > | > End Function > | > > | > -- > | > > | > Regards, > | > > | > Dave Patrick ....Please no email replies - reply in newsgroup. > | > Microsoft Certified Professional > | > Microsoft MVP [Windows] > | > http://www.microsoft.com/protect > | > > | > "Brenda" wrote: > | > | Hello, > | > | > | > | In a VBA module, how can I tell if a file exists before doing the > | > | TransferSpreadsheet? What I would like is something like this: > | > | > | > | filename = <calculated from some values on the form> > | > | if filename exists then > | > | ask for alternate file name > | > | endif > | > | > | > | > | > | Thank you, > | > | > | > | Brenda > | > | > | > | > | > > | > > | > | > >
|
|
I think it boils down to what you're comfortable programming with. I've been using scripting objects for ages in my MDB front-ends without issue. Speed-wise (though I only spent a few minutes) it appears there is no difference.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Douglas J Steele" wrote: | Any time you introduce an additional COM library, there's overhead. It may | not add an appreciable amount of time, but it's definitely there, and is | just one more thing that can go wrong. | | -- | Doug Steele, Microsoft Access MVP | http://I.Am/DougSteele | (no e-mails, please!)
|
|
You're missing the point I'm trying to make. Adding additional libraries increases the complexity of the application, and (if you're using early binding) can actually cause the application to fail. (Problems with the References collection can occur when the client machine has different versions of the referenced libraries than the development machine)
Sometimes (but not very often), FSO is necessary. This isn't one of those cases.
However, it's your application, so whatever makes you happy with it...
-- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no private e-mails, please)
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:Oook$OTQGHA.2012[ at ]TK2MSFTNGP14.phx.gbl...
[Quoted Text] >I think it boils down to what you're comfortable programming with. I've >been > using scripting objects for ages in my MDB front-ends without issue. > Speed-wise (though I only spent a few minutes) it appears there is no > difference. > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> > "Douglas J Steele" wrote: > | Any time you introduce an additional COM library, there's overhead. It > may > | not add an appreciable amount of time, but it's definitely there, and is > | just one more thing that can go wrong. > | > | -- > | Doug Steele, Microsoft Access MVP > | http://I.Am/DougSteele> | (no e-mails, please!) > >
|
|
No, not missing the point. I've never needed to add any reference library for this object. AFAIK it exists natively for any OS greater than Windows NT
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Douglas J. Steele" wrote: | You're missing the point I'm trying to make. Adding additional libraries | increases the complexity of the application, and (if you're using early | binding) can actually cause the application to fail. (Problems with the | References collection can occur when the client machine has different | versions of the referenced libraries than the development machine) | | Sometimes (but not very often), FSO is necessary. This isn't one of those | cases. | | However, it's your application, so whatever makes you happy with it... | | -- | Doug Steele, Microsoft Access MVP | http://I.Am/DougSteele | (no private e-mails, please)
|
|
Dave, I don't think you are atuned to the point Douglas is making.
This is not about needing to register libraries with Windows. It is about the fact that, in any Access application, you must select the libraries you wish to use (Tools | References, in the code window), and that any additional library has the potential to break the entire Access application, so that no code works. Like Douglas, I eschew any additional libraries beyond the 3 basic ones, unless they are absolutely necessary. This comes from hard experience with applications that break due to the Calendar control that installs with Access, other Microsoft controls such as the common dialog, 3rd-party ActiveX controls, and so on which are all subject to breaking with versioning issues, other badly behaved software that messes with their registration. Even the Office library breaks with the runtime, and referencing other Office application libraries breaks with version changes.
Given the damage that a bad reference can do (breaking the entire application), and the issues involved with verifying your libraries work okay, e.g.: http://www.trigeminal.com/usenet/usenet026.asp?1033 you are listening to the voice of experience telling you, "Avoid references you don't need." KISS.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:eTvkEsYQGHA.1556[ at ]TK2MSFTNGP09.phx.gbl...
[Quoted Text] > No, not missing the point. I've never needed to add any reference library > for this object. AFAIK it exists natively for any OS greater than Windows > NT > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> > "Douglas J. Steele" wrote: > | You're missing the point I'm trying to make. Adding additional libraries > | increases the complexity of the application, and (if you're using early > | binding) can actually cause the application to fail. (Problems with the > | References collection can occur when the client machine has different > | versions of the referenced libraries than the development machine) > | > | Sometimes (but not very often), FSO is necessary. This isn't one of > those > | cases. > | > | However, it's your application, so whatever makes you happy with it... > | > | -- > | Doug Steele, Microsoft Access MVP > | http://I.Am/DougSteele> | (no private e-mails, please)
|
|
Thanks Allen. I'm not talking about operating system library registrations. I'm talking about application references the same as you and Doug. I use late binding for the some of the various scripting objects and the excel.application object and in doing so I never have had to Tools|References|Add for these particular objects since they natively exist for the operating system and or the basic Office installation on our images. Also I always destroy these objects when I'm done using them.
Are you telling me there's a problem with this method? So far I've had good results with this.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Allen Browne" wrote: | Dave, I don't think you are atuned to the point Douglas is making. | | This is not about needing to register libraries with Windows. It is about | the fact that, in any Access application, you must select the libraries you | wish to use (Tools | References, in the code window), and that any | additional library has the potential to break the entire Access application, | so that no code works. Like Douglas, I eschew any additional libraries | beyond the 3 basic ones, unless they are absolutely necessary. This comes | from hard experience with applications that break due to the Calendar | control that installs with Access, other Microsoft controls such as the | common dialog, 3rd-party ActiveX controls, and so on which are all subject | to breaking with versioning issues, other badly behaved software that messes | with their registration. Even the Office library breaks with the runtime, | and referencing other Office application libraries breaks with version | changes. | | Given the damage that a bad reference can do (breaking the entire | application), and the issues involved with verifying your libraries work | okay, e.g.: | http://www.trigeminal.com/usenet/usenet026.asp?1033 | you are listening to the voice of experience telling you, "Avoid references | you don't need." KISS. | | -- | Allen Browne - Microsoft MVP. Perth, Western Australia. | Tips for Access users - http://allenbrowne.com/tips.html | Reply to group, rather than allenbrowne at mvps dot org.
|
|
No takers?
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
|
|
I think it's best to leave it with you.
Once you've been through a few versions of Access and Windows, with updates and patches and issues with the Microsoft DLLs, I'm sure you will understand.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:uAYqpOMRGHA.2176[ at ]TK2MSFTNGP10.phx.gbl...
[Quoted Text] > No takers?
|
|
OK, whatever......... thanks Allen. But that doesn't help me very much and I do value your opinion. I've been using this sort of method since version 97
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Allen Browne" wrote: |I think it's best to leave it with you. | | Once you've been through a few versions of Access and Windows, with updates | and patches and issues with the Microsoft DLLs, I'm sure you will | understand. | | -- | Allen Browne - Microsoft MVP. Perth, Western Australia. | Tips for Access users - http://allenbrowne.com/tips.html | Reply to group, rather than allenbrowne at mvps dot org.
|
|
I'm just curios to find out what method you all use since setting references is out and my methods of using automation objects from CreateObject and GetObject are also out.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
|
|
To check for whether a file exists?
As I originally posted, Len(Dir(strFilePath)) > 0
Note, too, that I never said that there aren't times when setting references isn't okay (although I usually use Late Binding instead). My comment was strictly that there are extremely few cases where FSO is required, as you can do almost everything FSO can do with straight VBA commands. For those few cases where VBA can't do it, I prefer to use APIs.
FWIW, I wrote an article comparing VBA to FSO to APIs for searching for files for Access Advisor a while back. As part of the article, I had a chart that compared the time for the 3 approahcs. To find 5491 MP3 files on my hard drive, the API approach was about 10 times faster than the Dir function (.191 seconds vs. 1.222 seconds), while the Dir function was about 10 times faster than the FSO approaches (1.222 seconds vs. 10.285 or 10.295 seconds).
-- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no private e-mails, please)
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:OLUAfSVRGHA.4956[ at ]TK2MSFTNGP09.phx.gbl...
[Quoted Text] > I'm just curios to find out what method you all use since setting > references > is out and my methods of using automation objects from CreateObject and > GetObject are also out. > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> >
|
|
Nope not at all. This thread moved from that discussion to setting references and late binding in general. The latter is what I usually use but Allen seemed to be hinting that wasn't a good idea but never did really answer either.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Douglas J. Steele" wrote: | To check for whether a file exists? <snip>
|
|
I see nothing in this thread that talks about either of those topics! I know I never mentioned either, and the only input from Allen is
"I think it's best to leave it with you.
"Once you've been through a few versions of Access and Windows, with updates and patches and issues with the Microsoft DLLs, I'm sure you will understand."
-- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no private e-mails, please)
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:OfXFv%23VRGHA.3192[ at ]TK2MSFTNGP09.phx.gbl...
[Quoted Text] > Nope not at all. This thread moved from that discussion to setting > references and late binding in general. The latter is what I usually use > but > Allen seemed to be hinting that wasn't a good idea but never did really > answer either. > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> > "Douglas J. Steele" wrote: > | To check for whether a file exists? > <snip> > >
|
|
This is just fabulous. LOL............
"You're missing the point I'm trying to make. Adding additional libraries increases the complexity of the application"
"It is about the fact that, in any Access application, you must select the libraries you wish to use (Tools | References, in the code window), and that any additional library has the potential to break the entire Access application, so that no code works. Like Douglas, I eschew any additional libraries beyond the 3 basic ones, unless they are absolutely necessary"
Do you let anyone else play this one? Thanks guys.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup. Microsoft Certified Professional Microsoft MVP [Windows] http://www.microsoft.com/protect
"Douglas J. Steele" wrote: |I see nothing in this thread that talks about either of those topics! I know | I never mentioned either, and the only input from Allen is | | "I think it's best to leave it with you. | | "Once you've been through a few versions of Access and Windows, with updates | and patches and issues with the Microsoft DLLs, I'm sure you will | understand." | | | -- | Doug Steele, Microsoft Access MVP | http://I.Am/DougSteele | (no private e-mails, please)
|
|
I'm serious, Dave, those entries don't show up in the thread when I look at it! (I use OE, and connect directly to msnews.microsoft.com) However, now that you've posted them, I do recall them.
Given this new information (<g>), what exactly is your question?
Allen & I are both saying not to use additional libraries (be it early bound or late bound) unless it's necessary. I maintain that FSO is rarely (if ever) necessary.
-- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no private e-mails, please)
"Dave Patrick" <DSPatrick[ at ]nospam.gmail.com> wrote in message news:Ozmws%23WRGHA.4956[ at ]TK2MSFTNGP09.phx.gbl...
[Quoted Text] > This is just fabulous. LOL............ > > "You're missing the point I'm trying to make. Adding additional libraries > increases the complexity of the application" > > "It is about the fact that, in any Access application, you must select the > libraries you wish to use (Tools | References, in the code window), and > that > any additional library has the potential to break the entire Access > application, so that no code works. Like Douglas, I eschew any additional > libraries beyond the 3 basic ones, unless they are absolutely necessary" > > > Do you let anyone else play this one? Thanks guys. > > -- > > Regards, > > Dave Patrick ....Please no email replies - reply in newsgroup. > Microsoft Certified Professional > Microsoft MVP [Windows] > http://www.microsoft.com/protect> > "Douglas J. Steele" wrote: > |I see nothing in this thread that talks about either of those topics! I > know > | I never mentioned either, and the only input from Allen is > | > | "I think it's best to leave it with you. > | > | "Once you've been through a few versions of Access and Windows, with > updates > | and patches and issues with the Microsoft DLLs, I'm sure you will > | understand." > | > | > | -- > | Doug Steele, Microsoft Access MVP > | http://I.Am/DougSteele> | (no private e-mails, please) > >
|
|
|
|
|