Create a record

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Silvia Zamora - 28 Feb 2005 18:23 GMT

Hi i've use VB in the past but just for really simple things and i'm a
little bit lost here.

I want a make a record, to put it in some way, so i be able to write this
record in a file, so i won't be writting piece by piece of info into it.
So i want this:
Lenght Start
Id number 5 1
Name 20 6
DOB 9 27

and so on, any help will be apreciated

Reply to this Message

Veign - 28 Feb 2005 18:25 GMT

Record for what? Text File, Database?

Signature

Chris Hanscom - Microsoft MVP (VB)
Veign's Resource Center
http://www.veign.com/vrc_main.asp
--

> Hi i've use VB in the past but just for really simple things and i'm a
> little bit lost here.
[quoted text clipped - 8 lines]
>
> and so on, any help will be apreciated

Reply to this Message

Silvia Zamora - 28 Feb 2005 18:36 GMT

Sorry, just for a text file i'm going to export it to another program.

Reply to this Message

Veign - 28 Feb 2005 18:38 GMT

See Mike's post then

Signature

Chris Hanscom - Microsoft MVP (VB)
Veign's Resource Center
http://www.veign.com/vrc_main.asp
--

> Sorry, just for a text file i'm going to export it to another program.

Reply to this Message

Mike D Sutton - 28 Feb 2005 18:34 GMT

> Hi i've use VB in the past but just for really simple things and i'm a
> little bit lost here.
[quoted text clipped - 8 lines]
>
> and so on, any help will be apreciated

Use a UDT for this:

'***
Private Type typMyRecord
IDNumber As String * 5
Name As String * 20
pad As String * 7
DOB As String * 9
End Type

...

Dim MyRec As typMyRecord
Dim FNum As Integer

MyRec.IDNumber = "12345"

FNum = FreeFile()
Open "X:\Path\File.xyz" For Binary As #FNum
Put #FNum, , MyRec ' Write structure
Seek #FNum, 1
Get #FNum, , MyRec ' Read structure
Close #FNum
'***

Any reason you didn't want to make the DIB start directly after the name, or just to make your life difficult? :)
Also, you can use the same technique to store non textual data such as dates and numbers if they would suffice for your
application, just declare your UDT members as different types and the same code should cope just fine.
Hope this helps,

Mike

- Microsoft Visual Basic MVP -
E-Mail: EDais@mvps.org
WWW: Http://EDais.mvps.org/

Reply to this Message

Rick Rothstein - 28 Feb 2005 19:17 GMT

> > I want a make a record, to put it in some way, so i be able to write this
> > record in a file, so i won't be writting piece by piece of info into it.
[quoted text clipped - 29 lines]
> Close #FNum
> '***

Personally, I wouldn't waste my time with a UDT for something this
simple. Yes, I probably would use the fixed with Strings just to make
things simple, but I think straight string concatenation to produce the
record makes just as much sense as using a UDT. To read it back, I would
just use the Left$, Mid$ and Right$ functions to retrieve the parts.

' Declare these so they have the proper scope
Dim IDNumber As String * 5
Dim PersonsName As String * 20
Dim DOB As String * 9
.....
.....
' To store a record
Dim FNum As Integer
FNum = FreeFile
Open "X:\Path\File.xyz" For Output As #FNum
Print IDNumber & PersonsName & DOB
Close #FNum
....
....
' To retrieve a record
Dim FNum As Integer
Dim Record As String
Open "X:\Path\File.xyz" For Output As #FNum
Line Input #FNum, Record
Close #FNum
IDNumber = Left$(Record, 5)
PersonsName = Mid$(Record, 6, 20)
DOB = Right$(Record, 9)

> Any reason you didn't want to make the DIB start directly after the name, or just to make your life difficult? :)

I assumed the OP simply erred by adding the string length to the sum of
start values.

Rick - MVP

Reply to this Message

Mike D Sutton - 28 Feb 2005 19:39 GMT

> Personally, I wouldn't waste my time with a UDT for something this
> simple. Yes, I probably would use the fixed with Strings just to make
> things simple, but I think straight string concatenation to produce the
> record makes just as much sense as using a UDT. To read it back, I would
> just use the Left$, Mid$ and Right$ functions to retrieve the parts.

Yes, you would.. ;)
For multiple records (which I would assume given the wording of the OP) the UDT method would save having to bother with
any of that and offer better performance since the string concatenations/splitting doesn't have to be performed. Also
the UDT copes well with changing the record format, a string manipulation technique would have to be re-coded to sync.
with the new record structure which opens you up to bugs too.
In addition to that, as mentioned in my prior post the members of the UDT are not limited to strings - IDNumber could
for example be converted to a Long and DOB to a Date, in both cases offering an increased range in _less_ space and in a
format ready to be used directly in calculations without having to perform a conversion to/from strings every time.
All in all UDTs look like a far easier, flexible and safer solution IMO, but each to their own :)

> I assumed the OP simply erred by adding the string length to the sum of
> start values.

Ah yes, well spotted. In which case simply get rid of the pad member from my UDT definition and the correct offset is
used (of course if that offset was used in the string concatenation/splitting method then it would have caused all kinds
of problems ;)) *vbg*
Hope this helps,

Mike

- Microsoft Visual Basic MVP -
E-Mail: EDais@mvps.org
WWW: Http://EDais.mvps.org/

Reply to this Message

BT3 - 28 Feb 2005 21:01 GMT

What's wrong with you guys? Make an INI file to store the definition and
use the API to retrieve it, piece by pain-staking piece. Then use the LOF
function to determine the file size, and calculate the number of anticipated
records. Create a variant and populate it with a template for the entire
file. Then sequentially fill it with Input#. Don't forget to build a
tracking file as you go, in case one of the records is improperly stored you
can error around it declaring the record as corrupt. :)

Assemblers do it on their hands and knees. Sorry, we just caught BTK, very
happy here. I feel like coding something.

BT3

> > Personally, I wouldn't waste my time with a UDT for something this
> > simple. Yes, I probably would use the fixed with Strings just to make
[quoted text clipped - 25 lines]
> E-Mail: EDais@mvps.org
> WWW: Http://EDais.mvps.org/

Reply to this Message

Rick Rothstein - 28 Feb 2005 21:08 GMT

> > Personally, I wouldn't waste my time with a UDT for something this
> > simple. Yes, I probably would use the fixed with Strings just to make
> > things simple, but I think straight string concatenation to produce the
> > record makes just as much sense as using a UDT. To read it back
> > I would just use the Left$, Mid$ and Right$ functions to retrieve

the parts.

> Yes, you would.. ;)
> For multiple records (which I would assume given the wording of the OP)
> the UDT method would save having to bother with any of that and offer
> better performance since the string concatenations/splitting doesn't have
> to be performed.

For the save option, if performance was to be an issue, we could always
pick up some speed by string stuffing a buffer using Mid$ in statement
form. I will concede that reading and splitting the record into
individual string variables won't be as fast as using a UDT, but at
least we wouldn't have to deal with a dotted reference to each of the
variable names elsewhere in code (sorry, but I really don't like that
aspect of UDTs, so it seems like a fair trade off to me.<g>).

> Also the UDT copes well with changing the record format, a string
> manipulation technique would have to be re-coded to sync. with the new
> record structure which opens you up to bugs too.

Of course, one should centralize the reading and writing functionalities
in subroutines to minimize that particular problem.

> In addition to that, as mentioned in my prior post the members of the UDT
> are not limited to strings - IDNumber could for example be converted

to a

> Long and DOB to a Date, in both cases offering an increased range in
> _less_ space and in a format ready to be used directly in calculations
> without having to perform a conversion to/from strings every time.
> All in all UDTs look like a far easier, flexible and safer solution IMO,
> but each to their own :)

True, if multiple types of data were to make up the record, the UDT
would be the way to go... but, of course, that was not the situation the
OP asked about.<g>

> > I assumed the OP simply erred by adding the string length to the sum of
> > start values.
>
> Ah yes, well spotted. In which case simply get rid of the pad member from my UDT definition and the correct offset is
> used (of course if that offset was used in the string concatenation/splitting method then it would have caused all kinds
> of problems ;)) *vbg*

The problem wouldn't be any worse than with UDT... providing we
centralized the reading and writing functionalities in subroutines as
mentioned above. If data was already saved out, the problem in
correcting the file would be the same with either method. If no data has
been saved yet, I would not think adjusting the code would be too
burdensome with either method.

Rick - MVP

Reply to this Message

VB Forum / General / February 2005

Create a record