Are sequential records required when using Get/Put? 1

[pachad]

Does anyone know if using Get # and Put # to place user defined variables into a output file requires that the files be placed sequentially?

i.e. can i execute the following, and reliably retrieve the data, or will it be corrupted since the output is not being done sequentially - there is no data for all records between numbers 2 - 499?

open "C:\Output.txt" for random as #1 len=len(MyVar)

put #1, 1, MyVar

put #1, 500, MyVar

close #1

-The file is being created with the open statement. MyVar is a user defined variable.

 

[MichaelRed]

hmmmmmmmmmm ... mmm ... mmm ... ?

Well you can write the 'foolishness'.

ASS U M ING you have also kept CAREFUL track of which records you have written you can also read them back.

What you get in attempting to read some non-initialized Record back is -at best- unpredictable.

Using your (at least implied) concept of simply placing the 'record' in a string - there by ASS U M ING it is a FIXED length string, the following (taken from the comedy of the absurd) 'works', leaving the issue of reasonablness to others (perhaps TLady would help with the logic and understanding of the point of it all?

Public Function basWriteAbsurd()

    Dim MyFil As Integer
    Dim MyVar As String * 50

    MyVar = String(50, "A")
    MyFil = FreeFile

    Open "C:\My Documents\Output.txt" For Random As #MyFil Len = Len(MyVar)

    Put #MyFil, 1, MyVar

    Put #MyFil, 500, MyVar

    Close #MyFil

End Function
Public Function basReadAbsurd()

    Dim MyFil As Integer
    Dim MyVar As String * 50

    'MyVar = String(50, "A")
    MyFil = FreeFile

    Open "C:\My Documents\Output.txt" For Random As #MyFil Len = Len(MyVar)

    Get #MyFil, 1, MyVar
    Debug.Print "Rec #1 = " & MyVar

    MyVar = String(50, "X")

    Get #MyFil, 23, MyVar
    Debug.Print "Rec #23 = " & MyVar
    MyVar = String(50, "M")


    Get #MyFil, 500, MyVar
    Debug.Print "Rec #500 = " & MyVar

    Close #MyFil

End Function

Try executing each and watching the so-called DEBUG window.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[pachad]

unused record numbers seem to return blank strings for the fixed string portion of the user defined variable, and 0 values for integers, single, double, and variant types.

object was to base record number on random numbers, which would not be sequential. thanks for your help.

 

[CajunCenturion]

When you use the Get and Put for randon files (or relative record files), the length and the record number are used to position the read pointer at the appropriate location in the file using the forumla (RecNum - 1) * RecLength.

The net effect is that is makes no difference when an individual record is written. The physical placement of that data is solely determined by the record number.

And you are correct, in that if you read a record that has not yet been written, you're most likely going to get default values for the given data types. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[MichaelRed]

It MAYbe system dependent, but my system doesn't iniatlize the file space inn any way, so values returned would generally just be whatever is 'left behind'. In the case of a (relatively) NEW disc or one that hse been recently re-formatted, the initalization (format process) would write Hex "00" , so the space would APPEAR to be blank. The number(s) bit is more likely caused by the coercion of the type by VB to whatever type you have placed in a UDT, and have little (nothing?) to do with the actual disc content. Trying the 'absurd' examples posted earlier, the non-initalized record returned 'gibberish' on my system, and the defined string for the initalized ones.

Still, I'm curious about why one would deliberatly choose a random value as the 'index' for a file like this, and -given that it has some utility - why you would choose a text file to store information. It seems like a simple table in .MDB format would be easier to deal with and provide at least the opportunity for some security for the information and a bit more flexibility in manipulating the information.

About the only advantage I would see would be in some economy of storage, particularly for small numbers of records. But this would need to be balanced aginst the somewhat more troublesome task of keeping up with the status of the possible records. Surely, the use of a 'random' record number will present you with some issues re the addition of records throughout the 'life cycle' of the app / process?

Referring to the implication of your (and my?) sample, we 'wrote' records 1 and 500, Realizing this MAY not be correct, but just as an example, I will assume that your random number routine is set to these as the bounds, so there will never be more than the 500. How, when you go to add another record, will you be able to determine that the new random number (record number) is not already in use? Given that you can reasonably accomplish this, let us further 'suppose' that the app / project is closing in on the magic limit of the 500 randomly assigned records, how are you going to generate a new record number - and, is it still a 'random' value.

To illustrate the last point, write a small routine which generates the list of 500 integers all of which are between 1 and 500 (inclusive). For each value 'sucessfully' added to the list, writ out the value, and the current time when the value was generated. Perhaps make the record number and time a UDT which you write to the test file. just to make it a bit easier to see the REAL results (how long does it take to find some of the latter values), also write the record number and data/time to either the debug window and / or a simple table.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places