Please add your comments and suggestions as a Reply to this thread.

PB/WIN - Random Access Files

PB/WIN - Random Access Files
Random access files consist of records that can be accessed in any sequence. This means the data is stored exactly as it appears in memory, thus saving processing time (because no translation is necessary) both in when the file is written and in when it is read.
Random files are a better solution to database problems than sequential files, although there are a few disadvantages. For one thing, random files are not especially transportable. Unlike sequential files, you cannot peek inside them with an editor, or type them in a meaningful way to the screen. In fact, moving a PowerBASIC random file to another computer or language will probably require that you write a translator program to read the random file and output a text (sequential) file.
One example of the transportability problem strikes close to home. Interpretive BASIC uses Microsoft's non-standard format for floating-point values, and PowerBASIC uses IEEE standard floating-point conventions, this means you cannot read the floating-point fields of random files created by Interpretive BASIC with a PowerBASIC program, or vice versa, without a bit of extra work.
The major benefit of random files is implied in their name: every record in the file is available at any time. For example, in a database of 23,000 alumni, a program can go straight to record number 11,663 or 22,709 without reading any of the other records. This capability makes it the only reasonable choice for large files, and probably the better choice for small ones, especially those with relatively consistent record lengths.
However, random access files can be wasteful of disk space because space is allocated for the longest possible field in every record. For example, a 100-byte comment field forces every record to use an extra 100 bytes of disk space, even if only one in a thousand actually uses it.
At the other extreme, if records are consistent in length, especially if they contain mostly numbers, random files can save space over the equivalent sequential form. In a random file, every number of the same type (Integer, Long-integer, Quad-integer, Byte, Word, Double-word, Single-precision, Double-precision, Extended-precision or Currency) occupies the same amount of disk space, regardless of the value itself. For example, the following five Single-precision values each require four bytes (the same space they occupy in memory):
By contrast, numbers in a sequential file require as many bytes as they have ASCII characters when printed (plus one for the delimiting comma if WRITE# was used instead of PRINT#). For example:
You can create, write, and read random access files using the following steps:
See AlsoReferences
Random files are a better solution to database problems than sequential files, although there are a few disadvantages. For one thing, random files are not especially transportable. Unlike sequential files, you cannot peek inside them with an editor, or type them in a meaningful way to the screen. In fact, moving a PowerBASIC random file to another computer or language will probably require that you write a translator program to read the random file and output a text (sequential) file.
One example of the transportability problem strikes close to home. Interpretive BASIC uses Microsoft's non-standard format for floating-point values, and PowerBASIC uses IEEE standard floating-point conventions, this means you cannot read the floating-point fields of random files created by Interpretive BASIC with a PowerBASIC program, or vice versa, without a bit of extra work.
The major benefit of random files is implied in their name: every record in the file is available at any time. For example, in a database of 23,000 alumni, a program can go straight to record number 11,663 or 22,709 without reading any of the other records. This capability makes it the only reasonable choice for large files, and probably the better choice for small ones, especially those with relatively consistent record lengths.
However, random access files can be wasteful of disk space because space is allocated for the longest possible field in every record. For example, a 100-byte comment field forces every record to use an extra 100 bytes of disk space, even if only one in a thousand actually uses it.
At the other extreme, if records are consistent in length, especially if they contain mostly numbers, random files can save space over the equivalent sequential form. In a random file, every number of the same type (Integer, Long-integer, Quad-integer, Byte, Word, Double-word, Single-precision, Double-precision, Extended-precision or Currency) occupies the same amount of disk space, regardless of the value itself. For example, the following five Single-precision values each require four bytes (the same space they occupy in memory):
Code:
0 1.660565E-27 15000.1 641 623000000
Code:
WRITE #1, 0;0 ' takes 3 bytes PRINT #1, 0;0 ' takes 5 bytes PRINT #1, 1.660565E-27 ' takes 13 bytes
- First, OPEN the file and specify the length of each record:
Code:OPEN filespec FOR RANDOM AS [#]filenum [LEN = recordsize]
- Define a structure for records in the file using the TYPE statement.
Code:TYPE StudentRecord LastName AS STRING * 20 ' A 20-character string FirstName AS STRING * 15 ' A 15-character string IDnum AS LONG ' Student ID, a Long-integer Contact AS STRING * 30 ' Emergency contact person ContactPhone AS STRING * 14 ' Their phone number ContactRel AS STRING * 8 ' Relationship to student. AverageGrade AS SINGLE ' Single-precision % grade END TYPE DIM Student AS StudentRecord
- Fill the UDTs members with the values you want, and write records to the file using the PUT statement.
Code:Student.LastName = "Anderson" Student.FirstName = "Bob" Student.IDnum = 494425610 Student.Contact = "Ma Anderson" Student.ContactPhone = "(800) BOBSMOM" Student.ContactRel = "Mother" Student.AverageGrade = 98.9 PUT #fileNumber, recordNumber, Student
- Read records from the file using the GET statement.
Code:GET #fileNumber, recordNumber, Student
- When finished, CLOSE the file.
Comment