File handling LOC(#FileNumber) inconsistancy.

[John Balshaw]

Hi,

I'm still wading my way through all my old programmes, but today had a real problem which took a fair amount of time to get to the bottom of.

I have a programme which buffered large numbers of small records from a file into memory, where it could then be dealt with far faster (I grabbed a single 13K lump of information rather than 1000 records of 13 bytes.) - this is all over a network, so the overhead for tiny records is massive.

My method for finding whether I needed to 'grab' another 1000 records information was using an integer division of the record number I was after by 1000 and then comparing that with LOC(FileNumber) - which in QBX returns the CURRENT record pointer.

In Powerbasic LOC returns the number for the NEXT record.

Looking through the documentation I see that LOC is due to be retired in favour of SEEK (which is fair enough, as currently they both do the same job), could I request that LOC be retained, but it regains compatibility with QBX?

Thanks, John

[John Strasser]

Of course you could.

And by the power invested in me by me I hereby give you permission to make that request to [email protected]

<grin> couldn't resist

[Bob Zale]

I understand that changing the functionality of LOC() might be a bit more convenient for one who is translating certain QB code. However, if we were to do that, every PowerBASIC customer who used LOC() would "instantly" have a broken program. It would not be pleasant to answer the phone here for a while.

I think it might be better to just change LOC(n) to LOC(n-1) or some such.

Thanks!

Bob Zale
PowerBASIC Inc.

[John Balshaw]

I think it might be better to just change LOC(n) to LOC(n-1) or some such.

Bob Zale
PowerBASIC Inc.

Or LOC(N)-1 even

Anyway, at least I'm not loosing the plot - it IS an incompatibility.

Regards, John

[Bob Zale]

You should probably keep in mind that PowerBASIC makes no claims of 100% compatibility with QB.

QB was abandoned by m$ some 21 years ago.

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

MACRO QbLoc (file) = SEEK (file) \ FILEATTR(File, -1&) (Maybe + 1? )

That's close, play with it. I don't do 'open for RANDOM' but once in a blue moon.

====Later

No, that's not close at all. When a file is opened RANDOM, SEEK Returns the next record to be read or written.

If your LOC() returns the last record read or written, then it's simply ....

MACRO QbLoc(file) = SEEK(file) -1

...right? (I think?) (THIS I *KNOW* is close)

[John Balshaw]

Yep,

That'll do the job perfectly, though having played around a while, I'm beginning to think I should concentrate a lot more on BINARY as it gets rid of the 32k record constraint.

Many thanks to all who've contributed.

Regards, John

[Michael Mattias]

... I'm beginning to think I should concentrate a lot more on BINARY as it gets rid of the 32k record constraint.

You have no such thing as a 32K record constraint, except as self-imposed for the purposes of keeping the network traffic "reasonable" (whatever "reasonable" means).

If dealing with 13-byte data records, I'd probably use the power of absolute arrays .

TYPE myData   ' 13 byte records 
   A AS LONG 
   B AS LONG 
   C AS LONG
   D AS STRING * 1
END TYPE 

%REC_PER_BLOCK  =   2000&    ' or whatever works for you 2K ==> 26000 bytes

FUCTION Foo () 

  LOCAL hIN AS LONG , m() AS MyType 
  LOCAL nBlock AS LONG, nOdd AS LONG 
  LOCAL i AS LONG, fs As LONG

  REDIM M(0)  ' so we can refer to it 

  hIn = FREEFILE 
  OPEN  "thefile" FOR BINARY AS hin BASE =  0
  fs =   LOF(hIn) 
  nBlock     = fs \ (SIZEOF(M(0) * %REC_PER_PER_BLOCK)  
  nOdd        = fs MOD SIZEOF(M(0))   ' number of records at end  of file
  FOR I = 1 TP nBlock
     GET$ hIn, SIZEOF(M(0)) * %REC_PER_BLOCK, S 
     REDIM  M (%REC_PER_BLOCK -1) AT STRPTR (S) 
     FOR Z = LBOUND (M,1) to UBOUND (M, 1) 
            A = M(Z).A 
            B = M(Z).B
            yadda yadda
     NEXT 
 NEXT
 GET$ hIn, nOdd , S 
 CLOSE hin   ' done with the file now. 
 REDIM  M( nOdd \ SIZEOF(M(0)) - 1) AT STRPTR(S) 
 FOR Z = LBOUND (M,1) to UBOUND (M, 1) 
            A = M(Z).A 
            B = M(Z).B
            yadda yadda
   NEXT

Tune as required for best network performance.

MCM