OPEN "R", 1, "employee.dat" 256
FIELD 1, 40 AS dat$(1), 40 AS dat$(2), 10 AS dat$(3), 30 AS dat$(4) . . .etc
RSET dat$(9)="EOR"
OPEN "R", 2, "name.dat" 64
FIELD 1, 40 AS dat$(21), 7 AS dat$(22), 17 AS dat$(23)
RSET dat$(23)="EOR"
the teacher stated that 7 AS dat$(22) is a pointer. i get the idea behind the pointer but i dont fully get why he chose the number 7.
I never knew that as a possibility, nor do I know how to use pointers from then on.
it isnt. your teacher has a skewed concept of pointers, which are a reference that qb cannot do. that just writes a field of 7 bytes in the record, and slaps dat$(22) in there. that's some of that random access nonsense that shouldnt be in qb.
more
here
:-? uhm. . .he did mention that name.dat would be a key file. does what he did makes more sense now? i see that as you do too toonski84 *(edited), thats why im confused on this.
...na_th_an?
He's probably trying to teach you how to use qb's "random access" to store records of things. I'd just take notes of what he says in class and ask if you have a problem, because he's just silly to call a record field a "pointer", unless I missed something, and he's using a archaic syntax to do it all. I guess what he's trying to say is that when you say "x as y$" that reserves x bytes so that when you are reading the file, x bytes of that are put into y$. To his credit, htough, it's the closest thing to pointers qb seems to have.
Quote:OPEN "R", 1, "employee.dat" 256
This opens the the file "
employee.dat" as a random access file ("
R"), at file handle
1, with records that are
256 bytes long.
Quote:FIELD 1, 40 AS dat$(1), 40 AS dat$(2), 10 AS dat$(3), 30 AS dat$(4) . . .etc
this defines your record. "FIELD 1" means open file handle 1. "40 AS dat$(1)" means that the first 40 bytes will be put into dat$(1). "40 as dat$(2)" means that the next 40 bytes will be put into dat$(2), etc.
Quote:RSET dat$(9)="EOR"
I'm a wee shaky on this, as i've never actually used random access files. From what I can tell, this puts a string into the record after you've defined the record with fIELD, in this case to tell your program when to to stop.
after you've defined a record, you can use get and put to read and write them. To be honest, i wouldnt be surprised if i made a lot of mistakes in logic here, i picked up most of this from the qb help files. I abhore random access files, as binary access files are easier and give you more control. But double check what I say, and if something your teacher says confuses you, ask him after class or something.
thanx toon. the class did ask him after class & we're all still lost @ how a field can be used as a pointer. its hard to distinguish from the "actual" fields. what i remember him saying is that the pointer has to be 7 bc that will allow a 9,000,000 record search, something like that, i dunno. we did about 200 lines of code on tuesday & this is the only part im stuck on. you're right about the EOR. the teacher said also that it shows you the end of a record when you're viewing in a hex editor.
ic ic ic
*STAB*....
Sorry, oracle has more posts than me.
Quote:ic ic ic
*STAB*....
Sorry, oracle has more posts than me.
:lol:
Methinks you'll find it easier if you learn about random access properly i.e. using TYPEs to control the format of the file.
And toonski, wouldn't those pointers be better off in a binary file anyway?
What I think is that ur teacher wasnt able to explain properly. And I too agree with Oracle, using 'pointers' in binary files is better. And you would be better off using Types in random acess files =)
ok, lets see how things go next tuesday as i grill the teacher about pointers. . .