Which is better: KILL or Filesystem object delete?

Hi,

Just as a point of interest I tend to use the FileSystem object to delete a file in VBA rather than just the KILL command.  I am just wondering which is the better way of doing this, I presume the FileSystem approach does take a little more resources to run as you need to create the object but besides that I was just interested in other peoples views on this.

    Dim filesys As FileSystemObject
    Set filesys = CreateObject("Scripting.FileSystemObject")
    filesys.DeleteFile "c:\temp.test.txt", True

OR
   
     Kill ("c:\temp.test.txt")


LVL 17
wobbledAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

TimCotteeHead of Software ServicesCommented:
Hello wobbled,

FIlesystemobject does indeed require more resources (and if you don't destroy it properly - which you don't show here) then it may keep hold of them too!

FSO has its place, which in my opinion is limited to scripting situations where you do not have alternative methods. Even here there are limitations because the FSO is part of an external library it may not be available on all machines.

Using the native functions is always more efficient and should be preferred over FSO methods.

Regards,

TimCottee
zorvek (Kevin Jones)ConsultantCommented:
When one considers efficiency one should also consider the context in which one is working. If you are deleting a single file then thinking about a few milliseconds here or there is a waste of time - we are long past the days of 32K machines and 8KHz processors. Only if you are deleting a large number of files should you even begin to consider the performance issues. Focus on the more computation intensive operations.

Kevin
GrahamSkanRetiredCommented:
Kill is the orignal VB intrinsic method for deleting files. It is simple and fast.

The FileSystemObject is intended to make programming file I/O easier.  It cannot be as fast ot light as Kill, and I would say that if you know the old methods and statements, and have only have a few file statements to implement, then stick to the intrinsic methods, rather than create a new object for a single statement.
Price Your IT Services for Profit

Managed service contracts are great - when they're making you money. Yes, you’re getting paid monthly, but is it actually profitable? Learn to calculate your hourly overhead burden so you can master your IT services pricing strategy.

wobbledAuthor Commented:
Cheers for the replies - you do make a good case for the Kill approach.  

One of the reasons I tend to use the FileSystem approach is the extra controls that it gives me, by that I mean I can do a FileExists call to check the file is there before / after etc.  I know I could use Dir.  As I tend to use this for any file manipulation I do (move copy rename etc) then I suppose it is out of habit that I do this.

Glad to hear your views.... always interesting

Thanks

TimCotteeHead of Software ServicesCommented:
wobbled:

It certainly does give you access to more properties and methods but of course to do so it acts as a wrapper around the native and api methods that are also available to you. The reason that it exists really is because scripted applications such as vbscript/asp etc do not have the ability to directly access api calls and functions so a handy wrapper for these common tasks was created ... the FileSystemObject (there are others that also wrap other api calls into "friendly" activex objects that can be used from scripts). It is indeed a matter of personal choice though I would always opt for the lowest relative complexity which generally speaking is to use the native function rather than an additional wrapper around that. However as has been pointed out earlier the need for compact and simple code is perhaps not as important as it was, though on the other side of that coin is the fact that use of more complexity when inappropriate leads to a general relaxation in the approach to efficient and effective code.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wobbledAuthor Commented:
Thanks for your feedback, I found it really informative and has made me think about my code style, which as most of you will probably agree - every now and again it is good to look at how you are writing code and is that the best way or just habit.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Office

From novice to tech pro — start learning today.