binary files

[badger]

Hello

Here is a stupid question but i have a need to know. Can you use binary files if you are storing only string values.

Badger

[bplus]

Yes specially if they are fixed length strings, otherwise you might have to mark the end of the strings.

[badger]

Hello

the whole type is made of fixed length strings

Thanks

[bplus]

@badger

You did see the conversation about using Binary access as opposed to Random access for what I assume to be data-base like app, the thread you started here: https://www.qb64.org/forum/index.php?topic=3064.msg123418#msg123418

I don't see need for headers but eh! I haven't data based since 90's.

[badger]

hello

can you maybe explain these two lines as to what they do. i know what the get does but why the math there

GET #1, LOF(1) / LEN(a), a
PRINT LOF(1), LEN(a), LOF(1) / LEN(a), a

Phil

[bplus]

LOF(1) / LEN(a) = number of records if "a" is a record, that length of file LOF / length of record = number of records, so getting last record and calling it "a".

Update: This GET #1, is for Random access.

Code: QB64: [Select]

1. DIM a AS STRING * 20
2. DIM i AS INTEGER
3. OPEN "myfiletest.txt" FOR RANDOM AS #1 LEN = LEN(a)  ' <<<<<<<<<<<<<<<<<<<< for RANDOM
4. DO
5.     READ a
6.     IF MID$(a, 1, 3) = "EOD" THEN EXIT DO
7.     i = i + 1
8.     PUT #1, i, a
9. LOOP
10. CLOSE #1
11.  
12. OPEN "myfiletest.txt" FOR RANDOM AS #1 LEN = LEN(a)
13. GET #1, LOF(1) / LEN(a), a
14. PRINT LOF(1), LEN(a), LOF(1) / LEN(a), a

Binary access you get a byte # not a record number (usually) .

In Binary you access byte amounts according to size of a, instead of records. So "a" has to be record size to get 1 record.

[Pete]

hello

can you maybe explain these two lines as to what they do. i know what the get does but why the math there

GET #1, LOF(1) / LEN(a), a
PRINT LOF(1), LEN(a), LOF(1) / LEN(a), a

Phil

Expanding a bit on what Mark posted... Okay, that was taken from the example I provided and was in response to your question about getting the last record in a binary file. The LOF() is the keyword for finding the entire length of the binary file. a was dim in that entire code snippet, to represent a string of characters, set at a fixed length; therefore, LEN() is the keyword that provides us with that length. When you divide the total length of the binary file LOF(1) by the length of the fixed string records LEN(a) you get the location of the last record. For instance, if the entire binary file is 500 bytes, and the length of each fixed string is 100 bytes, then the last record can be found at 500 / 100, which would be record #5.

Pete

[badger]

Hello

Thanks for the explanation the last i used quick basic style programming was back in the 90s and i never have used binary files. I have gotten an idea from reading on here that it seems to be maybe faster and more efficient so i wanted to try to use them. Yes it is a data base app with more than one file. The last time i wrote a database app was using qb4.5 and btrieve. if you are not familiar with btrieve. I used btrieve for dos 5.10a google it or goto pervasive.com and read up on the newest version. It is to expensive to buy now it is 5000.00 cant afford that so i have to come up with a way to access all the data and tie it together.

by the way I absolutely hate sql LOL

Badger

[badger]

Pete

Thanks for the expanded explanation of that. I thought that was what it was but now understand.

Badger