SEEK # or not SEEK #

[Dimster]

Running into a bad file name or number error message when using Seek on a sequential file and not sure why.

Open "d:/SequentialFile1" for INPUT as #52
Seek #52, Seek(1)

The above is generating the error message. I have checked the name of the file I'm trying to open, and that the file is indeed on my "d" drive, also that the same opening statement works with Input #52.

I checked the wiki and the example it provides drops the "#" . The wiki has the seek statement as SEEK 1, Seek(1) ( ie there is no "#").

I'm not sure which is the correct statement but no matter, both with or without the "#" I'm getting the error message. I have also tried to be sure the file I'm trying to access is Closed before the Opening statement.

Any idea's on what I could be doing wrong, and which to the two Seek statements is the correct one?

Thanks

[bplus]

Why use seek with a sequential file, you have to worry about CR and LF chr$(13) chr$(10)... and an EOF marker too I think?

Sequential files best for variable length data.

[SMcNeill]

Open "d:/SequentialFile1" for INPUT as #52
Seek #52, Seek(1)

This won't work at all the way you have it, nor for what you're trying to use it for.   Bare with me a bit, as I try and explain these various commands.

SEEK #55, whatever --- this is a SUB which you're calling.  https://wiki.qb64.org/wiki/SEEK_(statement)   It basically is a way to telling the program to move the file pointer to whatever position you want it at.

, Seek(1) ---  this is the FUNCTION which you're calling.  https://wiki.qb64.org/wiki/SEEK  It basically is a way of your programing asking where the file pointer of some file is currently at.

So:  SEEK #52, Seek(1) is basically saying:
Move the file pointer on (filehandle 52) to wherever the file pointer on (filehandle 1) is currently positioned.

Since you don't have an OPEN whateverFile$ FOR INPUT/OUTPUT AS #1, you're going to get an error as there's no open filehandle 1.


So, that's the FIRST reason why what you're trying isn't going to work.

The second reason is due to you OPENing the file in question FOR INPUT.

SEEK (as the SUB version) will place you directly at whatever byte you want to go to -- it doesn't track record positions at all.   It's only when you OPEN FOR RANDOM, that SEEK will move from one record to the next...

INPUT/OUTPUT/BINARY -- SEEK moves to byte position
RANDOM -- SEEK moves to record position


So, the only way something like this would be somewhat valid would be if:

OPEN "d:/SequentialFile1" For Random AS #52
Seek #52, Seek(52) + 1   'move to next record

Notice how all my file handles reference the same file, and that it's an Open For Random file?

I'm thinking the above is close to what you're shooting for, but I'm not certain as the original isn't really code which can do anything except error on you.  What exactly are you trying to do with the code here, after all?

OPEN "d:/SequentialFile1" For Random AS #52
Seek #52, 1   'move to first record
Seek #52, 3   'move to third record
Seek #52, Seek(52) + 2   'move two records past the current one

[Dimster]

Thanks guys but I thought I could OPEN a file with data stored sequentially or even randomly with any file number I wanted. I will often store data multiple files with negative values or multiple files with positive values and the subsequent OPEN uses either an even number for the file for the positive data and an odd number for the negative data. I could for example OPEN file #33 and file #52 with no problems at all. The vast majority of the time the files are OPEN for INPUT and the subsequent INPUT #33 and INPUT #52 has worked without problems. I hadn't realized that the file number was an issue with a Seek statement.

I forgot about RANDOM. I don't work a lot with Random but when I did, I thought the data had to be stored as Random and then retrieved as Random. That being said however, I don't work a lot with Seek either but was pretty sure it should have worked with sequentially stored data and what I was trying to do was reset my Inputs back to the beginning of the file (Seek (1)) and then For Loop to the data I want to work with. But I gather Seek works only with Random??

The other thing that has me puzzled is the Seek statement itself. I believe I use to be able to write Seek #32, 1 but the wiki seems to have that 2nd Seek in the statement ..SEEK 32, SEEK(1) and it has dropped the use of the "#"

[SMcNeill]

The # is optional in the SEEK statement.

SEEK #52, 1

is the same thing as

SEEK 52, 1

Think of it as being similar to the LET statement.  :)


And Seek works for all our modes -- it just works differently in RANDOM.

Let's say I have a data file that looks like:

ABCDEFGHIJKLMNO

16 bytes in that data file, correct?  (A to O is the file)

Now, if we OPEN thatfile FOR Input, Output, or Binary....

SEEK thatfile, 3   <-- this just moved our file marker to being in front of the third byte -- the "C".

Now, if we OPEN thatfile FOR Random ...  LEN = 4

SEEK thatfile, 3   <-- this just moved the file marker to being in front of the third RECORD -- the "I".  (Since we set our record size as being 4 bytes.  Record 1 is ABCD.  Record 2 is EFGH.  The start of record three is before the "I".)

Seek, with Random files works by records.  With everything else, it works by byte position.