Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1813 > unrolled thread

Re: Replacing text in a text file with VB6

Back to article view | Back to comp.lang.basic.visual.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Replacing text in a text file with VB6 dpb <none@non.net> - 2011-02-06 09:10 -0600
    Re: Replacing text in a text file with VB6 "Henning" <computer_hero@coldmail.com> - 2011-02-08 00:20 +0100
      Re: Replacing text in a text file with VB6 ralph <nt_consulting64@yahoo.net> - 2011-02-07 18:12 -0600
        Re: Replacing text in a text file with VB6 "Henning" <computer_hero@coldmail.com> - 2011-02-08 01:27 +0100
    Re: Replacing text in a text file with VB6 "StrandElectric" <Strand@dummyspit> - 2011-02-07 10:10 +1100
      Re: Replacing text in a text file with VB6 ralph <nt_consulting64@yahoo.net> - 2011-02-07 21:18 -0600
        Re: Replacing text in a text file with VB6 "jason@smkzone.com" <jbodine1@yahoo.com> - 2011-02-08 10:06 -0800
      Re: Replacing text in a text file with VB6 ralph <nt_consulting64@yahoo.net> - 2011-02-06 21:19 -0600
        Re: Replacing text in a text file with VB6 "StrandElectric" <Strand@dummyspit> - 2011-02-08 12:31 +1100
        Re: Replacing text in a text file with VB6 ralph <nt_consulting64@yahoo.net> - 2011-02-07 18:31 -0600
        Re: Replacing text in a text file with VB6 GS <gs@somewhere.net> - 2011-02-06 22:29 -0500
        Re: Replacing text in a text file with VB6 "StrandElectric" <Strand@dummyspit> - 2011-02-08 10:58 +1100
    Re: Replacing text in a text file with VB6 "StrandElectric" <Strand@dummyspit> - 2011-02-10 05:29 +1100
    Re: Replacing text in a text file with VB6 "jason@smkzone.com" <jbodine1@yahoo.com> - 2011-02-07 08:33 -0800
      Re: Replacing text in a text file with VB6 "StrandElectric" <Strand@dummyspit> - 2011-02-08 07:14 +1100
        Re: Replacing text in a text file with VB6 ralph <nt_consulting64@yahoo.net> - 2011-02-07 15:03 -0600
      Re: Replacing text in a text file with VB6 dpb <none@non.net> - 2011-02-07 11:47 -0600
      Re: Replacing text in a text file with VB6 Helmut_Meukel <Helmut_Meukel@bn-hof.invalid> - 2011-02-09 12:09 +0100

#1813 — Re: Replacing text in a text file with VB6

jason@smkzone.com wrote:
> That seems a little complicated just to get the top 3 lines and change
> them.  Is there a way to get just those three lines, set each to a
> different variable, and change them one by one?  I'm using If
> statements to change it, so that, for example:
...

LINE INPUT # will do that.

But, the thing is about sequential files is that....well, they're 
sequential.  So you'll still have to rewrite the whole file unless you 
get cute and read it as a binary and find the records and replace only 
the identical existing length.

--

[toc] | [next] | [standalone]

#1815

"ralph" <nt_consulting64@yahoo.net> skrev i meddelandet 
news:o1m0l65nor14ekpk9l7dmabcm3vhoee0c5@4ax.com...
> On Tue, 8 Feb 2011 07:14:31 +1100, "StrandElectric" <Strand@dummyspit>
> wrote:
>
>>
>>"jason@smkzone.com" <jbodine1@yahoo.com> wrote in message
>>news:12570ee9-67ce-4bd3-abb8-d994427c73ce@w7g2000pre.googlegroups.com...
>>Here's why I'm having trouble with doing it this way:
>>
>>the lengths of line 2 and line 3 will always be constant. A SSN is 9
>>numbers and the employee number will always be 4 numbers.  But names
>>are variable lengths. Plus, not every employee will have been hired at
>>the exact same time, so the number of clock in and clock out
>>timestamps is bound to be different from file to file, making for
>>different file lengths.  So wouldn't getting byte lengths and string
>>lengths, even with the Split function be useless in this context,
>>since those things change from one employee file to the next?
>>
>>The way I do it with random files is to allow a reasonable maximum for 
>>each
>>field.
>>
>
> Or to say it another way .. have headers, records, or sections of a
> fixed size. Then keep those sizes (and counts) available, to be
> translated to storage definitions or seek postions as required.
>
> In any case, if you intend to keep a bag of stuff (a data store) and
> intend to mine and modify specific elements in that bag, one of the
> first things you can do to make it easier on yourself is to define a
> layout or schema for that bag.
>
> You already had a workable definition:
> The top 3 lines of each file contains
> 1. The employee's name,
> 2. His or her SSN, and
> 3. His or her employee number.
> 4. more stuff ...
>
> In this case simply open the file.
> Grab the first 3 lines.
> Make your changes to those lines.
> Write the new lines to a new file.
> Write the rest (more stuff...) to the new file.
> Close the file.
> Delete the original file.
> Rename the new file to the old.
>
> You could try other schemes. Anything that creates unambiguous
> descriptions of 'what' and 'where'.
>
> -ralph

I would make a copy of the original file.

Copy the original file with a .bak extension.
Read from the .bak file
Write with overwrite to the original filename.
Keep the .bak file for the future or delete it at will.

If you ever need to change again, I guess the .bak file is old enough to be 
overwritten.

/Henning

[toc] | [prev] | [next] | [standalone]

#1820

On Tue, 8 Feb 2011 00:20:19 +0100, "Henning"
<computer_hero@coldmail.com> wrote:

>>
>> You already had a workable definition:
>> The top 3 lines of each file contains
>> 1. The employee's name,
>> 2. His or her SSN, and
>> 3. His or her employee number.
>> 4. more stuff ...
>>
>> In this case simply open the file.
>> Grab the first 3 lines.
>> Make your changes to those lines.
>> Write the new lines to a new file.
>> Write the rest (more stuff...) to the new file.
>> Close the file.
>> Delete the original file.
>> Rename the new file to the old.
>>
>> You could try other schemes. Anything that creates unambiguous
>> descriptions of 'what' and 'where'.
>>
>> -ralph
>
>I would make a copy of the original file.
>
>Copy the original file with a .bak extension.
>Read from the .bak file
>Write with overwrite to the original filename.
>Keep the .bak file for the future or delete it at will.
>
>If you ever need to change again, I guess the .bak file is old enough to be 
>overwritten.
>

ha, which leads us into fault-tolerance, audit trails, transactions,
... 

I'm sure we can come up with as many different schemes for that as for
how to organize the data in the file.

-ralph

[toc] | [prev] | [next] | [standalone]

#1834

"ralph" <nt_consulting64@yahoo.net> skrev i meddelandet 
news:c621l65aslil9mdkd2tnpis36hvihq5lq5@4ax.com...
> On Tue, 8 Feb 2011 00:20:19 +0100, "Henning"
> <computer_hero@coldmail.com> wrote:
>
>>>
>>> You already had a workable definition:
>>> The top 3 lines of each file contains
>>> 1. The employee's name,
>>> 2. His or her SSN, and
>>> 3. His or her employee number.
>>> 4. more stuff ...
>>>
>>> In this case simply open the file.
>>> Grab the first 3 lines.
>>> Make your changes to those lines.
>>> Write the new lines to a new file.
>>> Write the rest (more stuff...) to the new file.
>>> Close the file.
>>> Delete the original file.
>>> Rename the new file to the old.
>>>
>>> You could try other schemes. Anything that creates unambiguous
>>> descriptions of 'what' and 'where'.
>>>
>>> -ralph
>>
>>I would make a copy of the original file.
>>
>>Copy the original file with a .bak extension.
>>Read from the .bak file
>>Write with overwrite to the original filename.
>>Keep the .bak file for the future or delete it at will.
>>
>>If you ever need to change again, I guess the .bak file is old enough to 
>>be
>>overwritten.
>>
>
> ha, which leads us into fault-tolerance, audit trails, transactions,
> ...
>
> I'm sure we can come up with as many different schemes for that as for
> how to organize the data in the file.
>
> -ralph

;)

/Henning

[toc] | [prev] | [next] | [standalone]

#1824

"dpb" <none@non.net> wrote in message 
news:iimdlf$37c$1@news.eternal-september.org...
> jason@smkzone.com wrote:
>> That seems a little complicated just to get the top 3 lines and change
>> them.  Is there a way to get just those three lines, set each to a
>> different variable, and change them one by one?  I'm using If
>> statements to change it, so that, for example:
> ...
>
> LINE INPUT # will do that.
>
> But, the thing is about sequential files is that....well, they're 
> sequential.  So you'll still have to rewrite the whole file unless you get 
> cute and read it as a binary and find the records and replace only the 
> identical existing length.
>

Which leads me to throw a complete spanner in the works. I would do it by 
using a random access file. You can then work on just the record you need. I 
presume that the database approach uses just serial files.  I've always used 
random myself, since 1980 (!) so I'm more comfortable with it. But don't let 
that change your approach. I'm the greenest of the green and struggling 
right now with vb.net (though I have got random access files working there 
too!).  At the moment, I much prefer vb6, mainly for its excellent help 
system and its support for printing, both of which are abysmal in vb.net! 

[toc] | [prev] | [next] | [standalone]

#1842

On Tue, 8 Feb 2011 12:31:27 +1100, "StrandElectric" <Strand@dummyspit>
wrote:

>
>On another note, since 'program' is being replaced by the shortened buzzword 
>'app', does that make us all mere 'applicators"?
>

lol, I made exactly same observation several months ago at an internal
seminar on development methodologies. In their case, using a mega-buck
pattern code generator and a massive framework, the description was
quite applicable.

-ralph

[toc] | [prev] | [next] | [standalone]

#1871

OK,  think I resolved this problem by making the name be line 3
instead of line one.  That way, since the other 2 lines are fixed
lengths, it will be no issue to determine where I am in the string
with the name.

Ok... One *last* question...  I'll post it in a new thread. lol

Jason

[toc] | [prev] | [next] | [standalone]

#1848

On Mon, 7 Feb 2011 10:10:58 +1100, "StrandElectric" <Strand@dummyspit>
wrote:

>
>"dpb" <none@non.net> wrote in message 
>news:iimdlf$37c$1@news.eternal-september.org...
>> jason@smkzone.com wrote:
>>> That seems a little complicated just to get the top 3 lines and change
>>> them.  Is there a way to get just those three lines, set each to a
>>> different variable, and change them one by one?  I'm using If
>>> statements to change it, so that, for example:
>> ...
>>
>> LINE INPUT # will do that.
>>
>> But, the thing is about sequential files is that....well, they're 
>> sequential.  So you'll still have to rewrite the whole file unless you get 
>> cute and read it as a binary and find the records and replace only the 
>> identical existing length.
>>
>
>Which leads me to throw a complete spanner in the works. I would do it by 
>using a random access file. You can then work on just the record you need. I 
>presume that the database approach uses just serial files.  I've always used 
>random myself, since 1980 (!) so I'm more comfortable with it. But don't let 
>that change your approach. I'm the greenest of the green and struggling 
>right now with vb.net (though I have got random access files working there 
>too!).  At the moment, I much prefer vb6, mainly for its excellent help 
>system and its support for printing, both of which are abysmal in vb.net! 
>

Not sure how that is a "complete spanner"?

There isn't any such thing as a "random access file". You can read the
data in a file sequentially or randomly. Sequential access implies
opening the file and advancing through it till you find the spot of
interest. Random access implies opening the file and moving directly
to a spot using a 'seek' instruction. 

Random access certainly has avantages over sequential access in terms
of speed and space for large files, however, both depend on knowing in
advance where to stop.

-ralph

[toc] | [prev] | [next] | [standalone]

#1854

"ralph" <nt_consulting64@yahoo.net> wrote in message 
news:0p21l6dq4d603jkg056984tb9fgmnd1a5o@4ax.com...
> On Tue, 8 Feb 2011 10:58:09 +1100, "StrandElectric" <Strand@dummyspit>
> wrote:
>
>>
>>"ralph" <nt_consulting64@yahoo.net> wrote in message
>>news:fimuk6dv5t81ums021k1f52tkmets4bdst@4ax.com...
>>> On Mon, 7 Feb 2011 10:10:58 +1100, >
>>>
>>> There isn't any such thing as a "random access file".
>>
>>Strange, nearly all of my books on vb6 (many published by Microsoft) 
>>explain
>>the term 'Random Access File' fully and highlight the differences from a
>>sequential access file. Of course, if you want to be picky I agree that in
>>the end whatever file you have it will write to disc in the same form
>>(manipulation of magnetic fields). At a physical level, therefore, they
>>would be the same. But by 'Random Access' it is implicit that this is a 
>>way
>>of organising the data so that you can go straight to the part of the file
>>(the record) where the required data is held, and that the data is 
>>organised
>>into fields of predetermined length.  Incidentally I do not use 'seek'.  I
>>use UDTs to organise the file and in the put and get statements identify 
>>the
>>required record number.  This has worked in a live accounting system used
>>daily for some years and producing Government required financiaal
>>statements.
>>
>
> I suspect that you are doing far less "random access" than you think
> you are.

***Ralph, I've already agreed that 'random access' ('direct' would be a 
better term) is merely a term for the particular way of organising file 
access and the syntax used (what is physically happening behind the scenes 
on the disk is anything but random (though it appears 'direct' to the 
programmer and user )). But if that way is good enough for the designers of 
vb6 then it's good enough for me!

>
> I'm equally sure your organization and navigation schemes work well as
> the same has also worked well for xBase (dBase, Clipper, FoxPro,
> CodeBase, ...) for twenty-five years.

***well 31 actually :), as it was fully described in interpreter BASIC, then 
GWBASIC, then QuickBasic, then vb6... and it's available in the dreaded 
dot.net too!  (Only there UDTs are replaced by Structures...).  But records 
can be put to and got from directly by reference to the wanted record, and 
of course the records can be searched too for required strings and so on.

On another note, since 'program' is being replaced by the shortened buzzword 
'app', does that make us all mere 'applicators"?

> -ralph
> 

[toc] | [prev] | [next] | [standalone]

#1861

On Tue, 8 Feb 2011 10:58:09 +1100, "StrandElectric" <Strand@dummyspit>
wrote:

>
>"ralph" <nt_consulting64@yahoo.net> wrote in message 
>news:fimuk6dv5t81ums021k1f52tkmets4bdst@4ax.com...
>> On Mon, 7 Feb 2011 10:10:58 +1100, >
>>
>> There isn't any such thing as a "random access file".
>
>Strange, nearly all of my books on vb6 (many published by Microsoft) explain 
>the term 'Random Access File' fully and highlight the differences from a 
>sequential access file. Of course, if you want to be picky I agree that in 
>the end whatever file you have it will write to disc in the same form 
>(manipulation of magnetic fields). At a physical level, therefore, they 
>would be the same. But by 'Random Access' it is implicit that this is a way 
>of organising the data so that you can go straight to the part of the file 
>(the record) where the required data is held, and that the data is organised 
>into fields of predetermined length.  Incidentally I do not use 'seek'.  I 
>use UDTs to organise the file and in the put and get statements identify the 
>required record number.  This has worked in a live accounting system used 
>daily for some years and producing Government required financiaal 
>statements. 
>

I suspect that you are doing far less "random access" than you think
you are.

I'm equally sure your organization and navigation schemes work well as
the same has also worked well for xBase (dBase, Clipper, FoxPro,
CodeBase, ...) for twenty-five years.

-ralph

[toc] | [prev] | [next] | [standalone]

#1873

In the case of using ADOX with text files (as this OP is doing), and so 
I believe the only option is sequential.

-- 
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

[toc] | [prev] | [next] | [standalone]

#1885

"ralph" <nt_consulting64@yahoo.net> wrote in message 
news:fimuk6dv5t81ums021k1f52tkmets4bdst@4ax.com...
> On Mon, 7 Feb 2011 10:10:58 +1100, >
>
> There isn't any such thing as a "random access file".

Strange, nearly all of my books on vb6 (many published by Microsoft) explain 
the term 'Random Access File' fully and highlight the differences from a 
sequential access file. Of course, if you want to be picky I agree that in 
the end whatever file you have it will write to disc in the same form 
(manipulation of magnetic fields). At a physical level, therefore, they 
would be the same. But by 'Random Access' it is implicit that this is a way 
of organising the data so that you can go straight to the part of the file 
(the record) where the required data is held, and that the data is organised 
into fields of predetermined length.  Incidentally I do not use 'seek'.  I 
use UDTs to organise the file and in the put and get statements identify the 
required record number.  This has worked in a live accounting system used 
daily for some years and producing Government required financiaal 
statements. 

[toc] | [prev] | [next] | [standalone]

#1825

"Helmut_Meukel" <Helmut_Meukel@bn-hof.invalid> wrote in message 
news:iitslg$e9n$1@news.eternal-september.org...
> jason@smkzone.com came up with this:
>> Here's why I'm having trouble with doing it this way:
>>
>> the lengths of line 2 and line 3 will always be constant. A SSN is 9
>> numbers and the employee number will always be 4 numbers.  But names
>> are variable lengths. Plus, not every employee will have been hired at
>> the exact same time, so the number of clock in and clock out
>> timestamps is bound to be different from file to file, making for
>> different file lengths.  So wouldn't getting byte lengths and string
>> lengths, even with the Split function be useless in this context,
>> since those things change from one employee file to the next?
>>
>
> Jason, you should really look-up Split in Online Help.
> The length of the substrings between the separators (e.g. CRLF) doesn't
> matter, Split will return an array of strings.
>
> However, given your scenario with different lengths for the name,
> you'll always have to read and write back the whole text file.
> You could avoid to overwrite the whole file if you always use the same
> length for the name (all names padded with blanks to the same length).
> Then it's possible to change the name by just overwriting these bytes in
> the file.
>
> Helmut.
>
The random access method avoids all that (albeit that there is some wasted 
file space -- but then disc capacities are hardly restrictive these days) 

[toc] | [prev] | [next] | [standalone]

#1837

Here's why I'm having trouble with doing it this way:

the lengths of line 2 and line 3 will always be constant. A SSN is 9
numbers and the employee number will always be 4 numbers.  But names
are variable lengths. Plus, not every employee will have been hired at
the exact same time, so the number of clock in and clock out
timestamps is bound to be different from file to file, making for
different file lengths.  So wouldn't getting byte lengths and string
lengths, even with the Split function be useless in this context,
since those things change from one employee file to the next?

Jason

On Feb 6, 9:10 am, dpb <n...@non.net> wrote:
> ja...@smkzone.com wrote:
> > That seems a little complicated just to get the top 3 lines and change
> > them.  Is there a way to get just those three lines, set each to a
> > different variable, and change them one by one?  I'm using If
> > statements to change it, so that, for example:
>
> ...
>
> LINE INPUT # will do that.
>
> But, the thing is about sequential files is that....well, they're
> sequential.  So you'll still have to rewrite the whole file unless you
> get cute and read it as a binary and find the records and replace only
> the identical existing length.
>
> --

[toc] | [prev] | [next] | [standalone]

#1846

"jason@smkzone.com" <jbodine1@yahoo.com> wrote in message 
news:12570ee9-67ce-4bd3-abb8-d994427c73ce@w7g2000pre.googlegroups.com...
Here's why I'm having trouble with doing it this way:

the lengths of line 2 and line 3 will always be constant. A SSN is 9
numbers and the employee number will always be 4 numbers.  But names
are variable lengths. Plus, not every employee will have been hired at
the exact same time, so the number of clock in and clock out
timestamps is bound to be different from file to file, making for
different file lengths.  So wouldn't getting byte lengths and string
lengths, even with the Split function be useless in this context,
since those things change from one employee file to the next?

The way I do it with random files is to allow a reasonable maximum for each 
field. 

[toc] | [prev] | [next] | [standalone]

#1875

On Tue, 8 Feb 2011 07:14:31 +1100, "StrandElectric" <Strand@dummyspit>
wrote:

>
>"jason@smkzone.com" <jbodine1@yahoo.com> wrote in message 
>news:12570ee9-67ce-4bd3-abb8-d994427c73ce@w7g2000pre.googlegroups.com...
>Here's why I'm having trouble with doing it this way:
>
>the lengths of line 2 and line 3 will always be constant. A SSN is 9
>numbers and the employee number will always be 4 numbers.  But names
>are variable lengths. Plus, not every employee will have been hired at
>the exact same time, so the number of clock in and clock out
>timestamps is bound to be different from file to file, making for
>different file lengths.  So wouldn't getting byte lengths and string
>lengths, even with the Split function be useless in this context,
>since those things change from one employee file to the next?
>
>The way I do it with random files is to allow a reasonable maximum for each 
>field. 
>

Or to say it another way .. have headers, records, or sections of a
fixed size. Then keep those sizes (and counts) available, to be
translated to storage definitions or seek postions as required.

In any case, if you intend to keep a bag of stuff (a data store) and
intend to mine and modify specific elements in that bag, one of the
first things you can do to make it easier on yourself is to define a
layout or schema for that bag.

You already had a workable definition:
The top 3 lines of each file contains
 1. The employee's name,
 2. His or her SSN, and
 3. His or her employee number.
 4. more stuff ...

In this case simply open the file.
Grab the first 3 lines.
Make your changes to those lines.
Write the new lines to a new file.
Write the rest (more stuff...) to the new file.
Close the file.
Delete the original file.
Rename the new file to the old.

You could try other schemes. Anything that creates unambiguous
descriptions of 'what' and 'where'.

-ralph

[toc] | [prev] | [next] | [standalone]

#1858

jason@smkzone.com wrote:
> Here's why I'm having trouble with doing it this way:

Which way is "this" here????

> the lengths of line 2 and line 3 will always be constant. A SSN is 9
> numbers and the employee number will always be 4 numbers.  But names
> are variable lengths. Plus, not every employee will have been hired at
> the exact same time, so the number of clock in and clock out
> timestamps is bound to be different from file to file, making for
> different file lengths.  So wouldn't getting byte lengths and string
> lengths, even with the Split function be useless in this context,
> since those things change from one employee file to the next?
...

Well, that was the point I was making--a sequential file is sequential 
and you'll have to deal w/ that if using sequential file structure.

_HOW_ you deal with it can go from the simple, straightforward obvious 
to accessing it by byte and determining wherein one is (not at all 
simple, necessarily, as your example would demonstrate).

In general, to deal w/ sequential files one has to begin at the 
beginning and progress to the end.  In most instances w/o extensive 
effort one cannot make modifications w/o rewriting the file in its 
entirety; that's just the nature of the beast unless one does restrict 
the form and changes very carefully and not use the ordinary means by 
which sequential files are processed.

If you want something other than that basically you need a different 
file organization.

--

[toc] | [prev] | [next] | [standalone]

#1878

jason@smkzone.com came up with this:
> Here's why I'm having trouble with doing it this way:
>
> the lengths of line 2 and line 3 will always be constant. A SSN is 9
> numbers and the employee number will always be 4 numbers.  But names
> are variable lengths. Plus, not every employee will have been hired at
> the exact same time, so the number of clock in and clock out
> timestamps is bound to be different from file to file, making for
> different file lengths.  So wouldn't getting byte lengths and string
> lengths, even with the Split function be useless in this context,
> since those things change from one employee file to the next?
>

Jason, you should really look-up Split in Online Help.
The length of the substrings between the separators (e.g. CRLF) doesn't
matter, Split will return an array of strings.

However, given your scenario with different lengths for the name,
you'll always have to read and write back the whole text file.
You could avoid to overwrite the whole file if you always use the same
length for the name (all names padded with blanks to the same length).
Then it's possible to change the name by just overwriting these bytes in
the file.

Helmut.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web