Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Read and write from/to text files 2

Status
Not open for further replies.

tg2003

IS-IT--Management
Feb 6, 2003
270
0
0
IL
Hello all,

I'm currently migrating from VB6 to VB.NET (2008) an application.
I have the following questions regarding r/w of text files:

1. In VB6 application, I have a log file and a "write to log" function, that opens, write and close the log file each time that function is called. What is considered better in .NET ? Open this file when the application is started, keeping it opened while the app is running, just writing to the file when the "write to log" function is called and close the file when the app is terminated, or the second choice - Just as I have in my VB6 app - open+write+close each time the function is called?

2. I've found many examples of r/w in VB.NET. Currently, I'm using this one:
Code:
Dim oFile As New FileStream("a.txt", FileMode.Append, FileAccess.Write)
Dim oWrite As New StreamWriter(oFile)
oWrite.WriteLine(Now)
oWrite.Close()

My question is - What is considered the most efficient and performance economical way when I have a function that read and write to a text file many times during one running of the app?

Thanks in advance!!
 
1 - In either VB6 or DotNet, open it for Append as and when you need it. Don't leave it open all the time.

2 - The StreamReader and StreamWriter are fine.

Martin.
 
Thanks!

Regarding my 2nd question: Is it good to open it as a new instance each time I call this function?
 
It has to be a new because you cant elseway pass the needed arguments to initiate the object. None of the needed args is shared... so 'new' is a must. The simplest (the constructor is overloaded) arg is the 'path'.
You can define one possible object (*1) and if you read/write in many different files to use the above reference many times (*2).
Code:
Dim sr as IO.StreamReader   '<--- *1

for i as integer=0 to 5
  sr = new IO.StreamReader(files(i))   '<--- *2
  ' your code
  sr.Close()     ' Close it!
  sr.dispose()   ' You may omit this and the next line
  sr=nothing     ' ~
next i

In the for/loop i show you that i use the 'sr' (created outside the loop once) and i 'new' it each time with a new path. Suppose the 'files' is a string array for demonstration purpose.
 
I suppose, as you would know the location of this log file whenever the application was running, you could if you wished open the stream and hold it as a class/instance variable somewhere, but if I were to sit down and do it myself, I would instantiate (create a new) instance of the stream from inside the logging method.

No sense holding a stream open all day that you don't actually need...

Martin.
 
I wouldn't either hold it open. When needed i would open-write-close. Well, if the file needs to be processed quite often ( say every second, more or less ), in order to have less memory consumption (open write close, open write close and so on) i could do 2 things. (may exist more)
1. Leave it open. Close it after say 20 operations and open it again. (wouldnt choose that way)
2. Do the logging in the memory, and before exiting the application, append the data to the real file.
... Just some thoughts.

As for the Dim sr as IO.StreamReader, you can write it almost anywhere you want. The side effect will be the scope. For example, if you do not write it, and write Dim sr as new IO.StreamReader(files(i)) in the for/loop directly, it will work too. But it will not be visible out of the loop structure. Your choise. ;)
 
2. Do the logging in the memory, and before exiting the application, append the data to the real file.
... Just some thoughts.
Personally that is what I would do/have done. Then you put your code in Try Catch blocks and dump the log to a file in a Finally so you always have your log if it completes correctly or has errors.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top