UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Filesystemobject Or Not, Access 2010    
 
   
SemiAuto40
post Apr 13 2018, 09:17 AM
Post#1



Posts: 630
Joined: 3-April 12
From: L.A. (lower Alabama)


Needing to delete file and do other file/folder operations. See that the FileSystemObject looks good for this... but I also see examples where the FileSystemObject is not used for this purpose. The question is... Is there and reason in a company network database where I would be better served doing this kind of operation one way or the other? Any gotcha out there or qualification?

Thanks in advance.
Go to the top of the page
 
DanielPineault
post Apr 13 2018, 09:34 AM
Post#2


UtterAccess VIP
Posts: 5,973
Joined: 30-June 11



Access has the Kill statement to delete files. As for "other file/folder operations" you'd need to elaborate for us to guide you better.

Everything depends on you needs. You may wish to use APIs so deleted file go to the recycle bin instead of just vanishing so if ever there is a mishap they can be retrieved, then again you may like it to just vanish. More information is needed.



--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
SemiAuto40
post Apr 13 2018, 09:56 AM
Post#3



Posts: 630
Joined: 3-April 12
From: L.A. (lower Alabama)


I have a network database application in progress for PDF files. When the application finds a PDF file in the folder is parses the name for information then.... copies the PDF from the 'Reviewed Files" to another network location. After the copy then I need the original PDF found in 'Reviewed Files' to go away forever. It seems from what I have read that the FileSystemObject is a scripting method and that there is a non-scripting way through VBA to accomplish file operations. What I have to have is fast and reliable on a corporate network.

Thank you.
Go to the top of the page
 
DanielPineault
post Apr 13 2018, 10:03 AM
Post#4


UtterAccess VIP
Posts: 5,973
Joined: 30-June 11



I'd simply used:

Kill statement
FileCopy statement (I have a function which employs this with error handling, see: http://www.devhut.net/2010/09/29/ms-access-VBA-copy-a-file/)



but there is nothing wrong with employing the FileSystemObject. Whatever you are more comfortable with at the end of the day.



--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
SemiAuto40
post Apr 13 2018, 10:14 AM
Post#5



Posts: 630
Joined: 3-April 12
From: L.A. (lower Alabama)


Thanks for the information!

Simply put is using the FileSystemObject and scripting method any slower than VBA code for a database application on a corporate network? What I am comfortable with is not a factor... I have to make sure it works well and fast as can be.
Go to the top of the page
 
DanielPineault
post Apr 13 2018, 10:26 AM
Post#6


UtterAccess VIP
Posts: 5,973
Joined: 30-June 11



In my experience, I've never really much of a difference either way, but it wouldn't be hard to setup a test and actually measure the performance on your network.

--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
SemiAuto40
post Apr 13 2018, 10:37 AM
Post#7



Posts: 630
Joined: 3-April 12
From: L.A. (lower Alabama)


My corporate network spans from rural Alabama to Los Angeles and speed of operation is a huge factor for success of the project.

Thank you for your time in being so gracious as to respond. uarulez2.gif
Go to the top of the page
 
DanielPineault
post Apr 13 2018, 10:39 AM
Post#8


UtterAccess VIP
Posts: 5,973
Joined: 30-June 11



Any time!




I truly think you best bet would be to build a simple test routine that iterates through multiple files copying, deleting using the various techniques to evaluate how they each perform on your network.



--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
jleach
post Apr 15 2018, 03:41 PM
Post#9


UtterAccess Editor
Posts: 9,926
Joined: 7-December 09
From: Staten Island, NY, USA


I've been doing Access/VBA work for more than 15 years now (shudder, I sound old!) and have never come across any compelling reason to use FSO over the basic built-in IO functions of VBA.

I tend to prefer the more basic toolset as it's less likely to change. I recall some years around there was some directory read/search method that was popular with FSO which I had always preferred the more simple VBA Dir() approach... some change in FSO killed that, and my code happily continued to motor on smile.gif

(I tend to take that approach everywhere... these days I (or my company) have touched base on just about every modern development platform, and I'll always prefer solid dependability over shiny new tools)

--------------------
Go to the top of the page
 
DanielPineault
post Apr 15 2018, 06:05 PM
Post#10


UtterAccess VIP
Posts: 5,973
Joined: 30-June 11



I then to agree with Jack on this. The KISS principle is best. But... with one exception, the Dir() function, as I found out one day, you can't use it and within it's own call, try and call a second instance. So, for iterating through subfolders and things like that FSO is the way to go, but for simple I/O stuff, commands like MkDir, Kill, FileCopy, Len, ... make the most sense.



--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
jleach
post Apr 16 2018, 05:24 AM
Post#11


UtterAccess Editor
Posts: 9,926
Joined: 7-December 09
From: Staten Island, NY, USA


My ignorance saved me on that one smile.gif I did the nested folder thing before I really understood recursion, so I would get directories A, B, C, D, then loop that to get A/1, A/2, B/1, B2, etc (instead of the more natural recursive way, which would be to get A, A1, A2, B, B1, B2, etc).

If I had known what I was doing I would have gotten it wrong!

Anyway, yea, that behavior of Dir() can be pest...

--------------------
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    15th August 2018 - 11:32 AM