Hi, I'm new around here & newish to VB 6.0 as well! :cheesy:

I'm using VB 6.0 to create a random access file, which has 2 fields per record . I know that all the records must be of equal length, but am wondering if there is a practical limit to the total number of bytes (or characters) that can be stored in a record of such a file.

If there is a maximum number here, what is it, please?

Though I use PowerBasic for windows instead of VB, i'm sure the record
length for random files is quite large as it is with PB. Of course it should
be kept in mind that many times the larger the record, the more likely
wasted space is increased which is inherent in random (i.e. fixed length)
files especially when there are name. address. city, comment fields etc.

Though I use PowerBasic for windows instead of VB, i'm sure the record
length for random files is quite large as it is with PB. Of course it should
be kept in mind that many times the larger the record, the more likely
wasted space is increased which is inherent in random (i.e. fixed length)
files especially when there are name. address. city, comment fields etc.

Thanks, Buff.

I've tried progressively increasing the record length, and VB 6.0 didn't complain! It will accept any value I'm likely to require, without hitting the ceiling, so I'm happy about that!

Agreed, random files can be quite wasteful on space. The two fields I've created each need to hold strings containing anything from 1 to 140 characters, so I'm compelled to set their lengths to the latter value. In an extreme case, a single ASCII character padded with 139 blanks would certainly not be economical!!

I don't know what alternatives exist to the use of random files, in order to save disc space. Sequential files are definitely out! I had wondered about binary files, but I read somewhere that these are generally used where the files are not going to be read by humans. To me this implies that there could be problems if I try to use them to store ordinary text.

Using a database is a possibility. VB 6.0 Pro version provides a form of database (Microsoft Access) ready built-in, but it appears to be a sawn-off version of the real thing. Have tried it out, but it will only allow me to search for a complete record. I have not persuaded it to look for a sub-string within a record. This is something that is very easy to do when my stuff is stored in one or more random files.

Ah well, I guess you pays your money & takes your choice! :)

Thanks, Buff.

I had wondered about binary files, but I read somewhere that these are generally used where the files are not going to be read by humans. To me this implies that there could be problems if I try to use them to store ordinary text.

I don't know who wrote that but I would say they are full of ___t.
LOL.

Besides, you can treat any file as a binary file.In fact when you get right down to it, all files are binary files in one sense.

I would say that if the maximum length is only 140 then random files would be
good. That is a relatively small record size so the computer will read the records pretty fast and with today's large hard drives it would amount to only 14 Mb if you have 100,000 records.

I would say that if the maximum length is only 140 then random files would be good. That is a relatively small record size so the computer will read the records pretty fast and with today's large hard drives it would amount to only 14 Mb if you have 100,000 records.

That's music to my ears, Buff. I shall stick to random files!

I'm writing a Spanish programme designed to assist English speakers to learn the language. The user can create any Topic he choses, (eg nouns, verbs, adjectives, notes of any description, extracts from a Spanish book, etc). For each Topic, a random file is created. Within a Topic, each Entry corresponds to a Record containing 2 string fields of 140 characters each, to hold respectively the English text & a corresponding Spanish version. ie, 280 characters per record.

It's impossible to predict how many Topics the user will create, or how many Entries he will place in each (depends upon how keen he is! :D ), but I envisage say, up to 100 such random files, with an average of 400 records in each. Anything in excess of that I would regard as exceptional!

Judging from what you say, although each record is 280 bytes, rather than the 140 I quoted previously, this level of usage should still scarcely make a dent on a large hard drive. (Specifically, 11.2 Mb, unless I've overlooked some other requirement). I guess there might be a problem with older machines where space is at a premium. That doesn't worry me unduly, 'cos I'm not distributing it for sale - just passing it on to a couple of unsuspecting family members!

The programme has various learning features, including a search facility & a test, with 10-50 randomly chosen questions, optionally against the clock, and a log file to which the test details, results & scores can be written. I have already got the programme up & running in QBasic, but I thought it would be fun & a challenge to create it again in Visual Basic, at which I am a raw beginner. It's proving to be an excellent way of learning Visual Basic. The more mistakes I make, the more I learn! It felt quite weird at first. In QBasic, you normally get the core code working first, then make the interface look pretty afterwards. With VB, it's the other way round. For me, that was the hardest part to swallow & took some getting used to! :eek: You've got to have at least a hazy idea of where you're going before you start to draw your user interface. At the time, seemed like trying to stick the wallpaper up first, then build the house afterwards.

Thanks for the help you've given me, Buff. I really appreciate it.

Hello i will like to have an exemple to help me understand random access file(user define data type) using dynamic array in vb6.
Please with explanation.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.