Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CONFUSING ARTICLE: Random Access Files - By Cruzan Wallis
#1
On the www.wbasicnews.com main page, ther's a section called "QbasicNews Latest Features". I just noticed the following article today and read it:

Random Access Files - By Cruzan Wallis
This article explains how and why to use random access files.

I can't find a thing in the article that explains how and why to use random access files. Maybe you're supposed to read between the lines. :roll:
*****
Reply
#2
The article is just a suggestion to use them. I'll put up a better example shortly. But basically they're easier to search through to specific records and remove them. I.e. you know exactly where it is and can edit/delete the contents easier.

E.g. You have a players.dat file with name of player/character, their attributes and inventory. If in a game the player lost his sword, you can then easily remove it from that specific player's record.
Reply
#3
Hi Wildcard, The reason I read the article is that in all the years that I've been using Basic, I've never had the need to use Random files.

In a few applications that had large files where I needed direct access to records, I used Btrieve, a database handler. The rest of the time I use plain old sequential access, especially now when the speed of I/O is blazing fast as compared to machines of 10-15 years ago.

I know nothing about games, but for the example you mention, I would probably keep the player info in memory --- how many players can there be? Or, I would read/write the players file sequentially updating the required record(s). I would need to test this to see the impact on the time.

P.S. I still would like to see other examples using Random.
*****
Reply
#4
Random is there only for backwards compatibility. It was the only way to have direct access to a file in QB versions 3.0 and below, Basic Compiler 5 and below, GWBASIC and BASICA. In QB 4.0 the BINARY mode was introduced, making the use of RANDOM unnecesary. The BINARY mode is way more flexible, faster and easier to use.

It is like when DO:LOOP was introduced. It extended the functionability of WHILE:WEND allowing "UNTIL" conditions and placing the condition at the end of the loop. WHILE:WEND is still there just for backwards compatibility, but it is no longer needed (although I still use it Tongue).
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#5
Nathan, Thanks for the good info. Now I guess I'll have to look into Binary mode and see what it offers. Does id offer direct access?
*****
Reply
#6
Sure, and it's terribly simple:

Code:
GET #file%, pos&, <data>
PUT #file%, pos&, <data>

Those, respectively, get <data> from or put <data> into the file. The number of bytes depends on the length of the data type the <data> variable is. For example,

GET #1, 10, a%

Will read two bytes from position 10 and will store them in a%

PUT #1, 200, great$

Will write LEN(great$) bytes from position 200 taken from the great$ string.

You can also use them to access a file sequentially. There is a file pointer just like in INPUT and OUTPUT sequential modes and you can tell QB to read or write from that position just not telling PUT or GET a position, and that pointer gets automaticly incremented by the size of the data read or written. For example, the following code will read a binary file completely byte to byte:

Code:
byte$ = " "   ' Just to make byte$ measure 1 byte.

f%=FREEFILE
OPEN "FILE.BIN" FOR BINARY AS #f%

WHILE NOT EOF(f%)
   GET #f%, , byte$
   PRINT "Byte read: "; ASC(byte$)
WEND
CLOSE #f%

You can also write or read a full record, QB will calculate how many bytes depending on the size of the custom data type, and will increase the file pointer correctly as well:

Code:
TYPE RecordType
   id AS INTEGER
   name AS STRING * 20
   age AS INTEGER
   phone AS STRING * 10
END TYPE

DIM myRecord AS RecordType

f%=FREEFILE
OPEN "FILE.DAT" FOR BINARY AS #f%

PUT #f%, , myRecord

CLOSE #f%

or the same way around:

Code:
GET #f%, , myRecord

As you see, this is far way more flexible than the old RANDOM mode, not limiting the size of the data/write read or where to read/write that data.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#7
Na_th_an

Do you know of where I can read up on using binary files? Tutorial or anything?
Reply
#8
Sorry, but appart from QB help (from which I learned how to use the BINARY mode) and the above post, I can't point you anywhere.

Anyhow, in my prev. post I explain it all. There isn't more stuff... Do you have any doubts? Ask them here Smile
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#9
jgr,

You just looked at an excellent tutorial on Binary mode above, by Nathan. Who could ask for more? Big Grin
*****
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)