80-Bus News

62

The program goes like this:

10 DIM N$(300),P$(300): ‘ Set up the maximum size of the arrays. 20 ‘ Reload the names array counting the number of entries in N. 30 ‘ Reload the phone numbers array.

40 ‘

50 ‘ Get the input name

60 INPUT “What is the name please (enter E to end) “;I$

70 IF I$="E” THEN 270

80 ,

90 ‘ Start the search of N$(A) for a match with I$

100 FOR A=0 TO N

110 IF N$(A)=I$ THEN 230

120 NEXT

430 ‘’

140 ‘ No find so see if it’s to be added, if so add it

150 INPUT “The name wasn’t found, do you want to add it (Y/N) “;J$ 160 IF J$="N” THEN PRINT: GOTO 60

170 N=N+1

180 INPUT “What is the new name please “;N$(N)

190 INPUT “What is the new number please “;P$(N)

200 PRINT: GOTO 60

210 ‘

220 ‘ Name found so print the result

230 PRINT I$;"’s phone number is “;P$(A)

240 PRINT: GOTO 60

250 *

260 ‘ End, so save the arrays

270 ‘ Down load from N$(0) to N$(N) to save the names

280 ‘ Down load from N$(O) to NS(N) to save the phone numbers 290 END

All very easy stuff, using two parallel one dimensional arrays, one, N$(n) as the key, the second P$(n) as the data. Notice that I chose to use a. string array for P$(n) even though it only contains numbers. This is because it needn’t only contain numbers, for instance I always write phone numbers, __-___-____, which certainly isn’t numeric (that isn’t my number by the way, so don’t try it.) Or P$(n) could contain an address as well as the phone number, or recipes (short ones as string length is restricted to 255 characters), or, well, you name it.

THE HARDER BIT

Having looked at both types of commonly used database, the random access and the sequential (and the sequential free field type) and having looked at the way in which the data would be split up into fields within the records in the file (neat summary that, databases consist of fields in a record in a file). It is plainly obvious that both types of database have snags when it comes to access. The sequential database can usually only be looked at in a sequential manner, which means that if the file is of any length, then access time to any record will depend on the position of that record within the file. If it happens to be at the end of the file it just takes a long time to get at, tuff!! The problem with the random access file is not so much the access time, it only takes a few milliseconds to move the disk head to the correct track/sector position, but how the devil do you know which is the correct track/sector position.