If you are talking about the issue of trying to append to the file you have
open for reading, here is how I understand it:
When a file is open for reading, it is generally locked, and unable to be
modified or appended to. This is because the reading and writing is, more or
less, sequential and synchronous[*]. It is possible for a file to have
multiple concurrent instances of being accessed, but that would need to be
through some sort of indexed I/O, such as is done in some database systems.
The overhead for doing so is not built into vbscript, and would be quite a
problem to script a solution. You might be able to use one of the COM
objects available for accessing database files with queries, but even ADO
does sequential reads (I think).
An alternative approach would be to maintain the computer list in a
spreadsheet, and access the required info by row/cell reference. While
technically feasible, I think that the complexity of the approach would
increase the scripting effort well beyond the benefits that might be
realized from this approach.
[*] another way to look at this is that when you read from a file
line-by-line, each character read does not come directly from the file
itself, but through some kind of buffering system. And when a file is
modified (i.e. changes are committed back to the storage device), this is
often done internally by writing a completely new copy of the file with
changes applied. So line one of the modified file might not be at the same
location it was when the unmodified file was first opened for reading.
First rule of scripting: keep it relatively simple; it's only scripting.
There are a lot of good references for the scripting language itself
("VBScript Programmer's Reference" from WROX), as well as some for specific
application areas (for example, "Windows NT/2000 ADSI Scripting for System
Administration" by Thomas Eck), and even a few general purpose books dealing
with the discipline of programming/app development ("Code Complete" by Steve
McConnell). Most of these will show you something about how certain tasks
could be scripted or programmed, but very few will concentrate on the sorts
of misconceptions the beginner might have about how things work.
Scripting is an arcane activity to say the least. Having an interest or
affinity for it as you do is a definite advantage. Much of the available
information is fact-oriented and targetted narrowly, leaving it to the
practitioner to develop his/her own understanding of how it all fits
together, how or why it works, and what is feasible versus what is not. My
best advice at this point can be summarized as:
- follow this and other related newsgroups
(microsoft.public.scripting.vbscript, microsoft.public.scripting.wsh);
- check out the available web sites, including the MS scripting centre;
- ask questions;
- challenge your own understanding about what you think you know.
The last point is the trickiest, as our own assumptions can be so ingrown
and self-evident that we often do not realize what they are let alone that
we have made them. When stuck on some point, learn to ask yourself why you
think a particular way.
I once had a supervisor who wanted me to develop a simple database to keep
track of something (I forget what it was). When I tried to explain to him
that there was no possible solution to the problem this was intended to
solve he said: "I can't imagine how it would be impossible to do this, as it
seems simple to me". He dropped the idea when I suggested that, in order to
actually do it, at least one of us would have to be able to imagine how it
*could* be done!
/Al