Binary File I/O with variable string member

[VJ]

Hi,

I am working on a small application and dont want to store records in any
database (access,sql. etc). I want to write & read

information from my own binary file, for this purpose I have declared type
in my application which is as follows.

Public Type CustDetails
CustID as long
FName as string
LName as string
Addr as string
City as string
State as string
Country as string
DateofBirth as date
Weight as double

 

[Bob Butler]

Hi,

I am working on a small application and dont want to store records in
any database (access,sql. etc). I want to write & read

information from my own binary file, for this purpose I have declared
type in my application which is as follows.

Public Type CustDetails
CustID as long
FName as string
LName as string
Addr as string
City as string
State as string
Country as string
DateofBirth as date
Weight as double
.
.
.
...etc. etc.
End Type


Now to save disk space I dont want to specify the length of string
type memebers.

I have declared the customer array and can save that customer array
into file easily but problem comes while loading this file back to
the customer array as I dont know what exactly would be the number of
records saved in this file so that i can redim my array accordingly.

My code for saving and retreving type array as follows


Dim arrCustomer() As CustDetails
Dim fso As New FileSystemObject
Private Const mFileName As String = "Customers.dat"

Private Sub SaveFile()
If GetUBound(arrCustomer) < 0 Then
Exit Sub
End If

Dim arrCounter As Integer
Dim FileNum As Integer
Dim DataFilePath As String
DataFilePath = App.Path & "\" & mFileName
FileNum = FreeFile
Open App.Path & "\" & mFileName For Binary As FileNum

Put #FileNum,, clng(ubound(arrCustomer)) ' record count

Put FileNum, , arrCustomer
Close (FileNum)

Make that: Close #FileNum
VB does not use () when you don't use CALL

MsgBox "Saved..", vbInformation
End Sub


Public Sub LoadFile()
Dim FileNum As Integer, RecordNumber As Integer
Dim DataFilePath As String

Dim RecordCount As Long

DataFilePath = App.Path & "\" & mFileName
If fso.FileExists(DataFilePath) Then
FileNum = FreeFile
Open App.Path & "\" & mFileName For Binary As FileNum

Get #FileName,,RecordCount
ReDim arrCustomer(RecordCount) ' this is a problem

Get FileNum, , arrCustomer

Close #FileNum

 

[Jeff Johnson [MVP: VB]]

Make that: Close #FileNum
VB does not use () when you don't use CALL

....and while you might say "it works fine for me," yes, in this instance it
does, but someday it'll bite you in the ass, so just avoid it and do it the
way Bob showed.

 

[J French]

Hi,

I am working on a small application and dont want to store records in any
database (access,sql. etc). I want to write & read

information from my own binary file, for this purpose I have declared type
in my application which is as follows.

While I wholeheartedly agree with you in doing your own filing, your
current approach is a bit ... fragile.

If anything goes wrong with one bit of your file, it will shaft the
whole thing and be very hard to fix.

You would be a lot better off storing the data in plain text that can
be inspected and modified with a simple text editor

Something like the INI file format will do the trick

While it looks as if the processor is doing a lot more work, the work
is taking place in memory - and that is extremely fast

The advantages of being able to manually inspect your data and
physically fix/modify it are well worth considering.

It would also be an idea to 'wrap' the whole lot in a Class, which
will allow you to change/update your strategy without having to modify
Application code.

 

[Ralph]

While I wholeheartedly agree with you in doing your own filing, your
current approach is a bit ... fragile.

If anything goes wrong with one bit of your file, it will shaft the
whole thing and be very hard to fix.

You would be a lot better off storing the data in plain text that can
be inspected and modified with a simple text editor

Something like the INI file format will do the trick

While it looks as if the processor is doing a lot more work, the work
is taking place in memory - and that is extremely fast

The advantages of being able to manually inspect your data and
physically fix/modify it are well worth considering.

It would also be an idea to 'wrap' the whole lot in a Class, which
will allow you to change/update your strategy without having to modify
Application code.

I agree with this.

It is also useful to borrow a page from .dbf files (arguably the most
successful data file format after diff files ever invented) and include a
header providing at a minimum version information, and perhaps field order
and type.

Mr French's advise concerning flexibility is particularly germaine to the
example you gave. I was with you (something light-weight) until I saw
"country" and the absence of any "Postal Code" or other legal political
divisions - what about mutliple line 'addresses'? Weight measured in what?
Date format? ...

Second I would be concerned that whenever one goes about creating a bag of
loosely related 'attributes' they are destined to create a data-centric
application with all the pitfalls such a strategy will entail.

-ralph

 

[J French]

On Thu, 22 Dec 2005 07:22:40 -0600, "Ralph"

I agree with this.

It is also useful to borrow a page from .dbf files (arguably the most
successful data file format after diff files ever invented) and include a
header providing at a minimum version information, and perhaps field order
and type.

I would advocate moving on a step from .DBF
- tags (or mnemonics) are very useful

Mr French's advise concerning flexibility is particularly germaine to the
example you gave.

Ahem, Ralph - it is Jerry

I was with you (something light-weight) until I saw
"country" and the absence of any "Postal Code" or other legal political
divisions - what about mutliple line 'addresses'? Weight measured in what?
Date format? ...

Add the fields on the fly - it works

Second I would be concerned that whenever one goes about creating a bag of
loosely related 'attributes' they are destined to create a data-centric
application with all the pitfalls such a strategy will entail.

Sort of yes and no there
- black box the source (and updating) of the data and one is pretty
much there

Ultimately all data items have to have a name
... it is a matter of skill and judgement
(AKA learning from ones mistakes)

 

[Jeff Johnson [MVP: VB]]

Ahem, Ralph - it is Jerry

Nah. Ralph needs to be kept in his place....

 

[Ralph]

Nah. Ralph needs to be kept in his place....

LOL

Actually being often wrong does the trick.

-ralph