IDX file format

[JF Mous]

Hi Dale & co,

I've not been working with POS for a while since I as doing other projects, but I've started again this week and here I am already with another question:

I'm working on a tool that allows me to add additional data to the stock table (things such as a sales place etc...)

But I've come along another problem: The IDX file used to contain 4 bytes per stock table item, but it seems to me that's changed.
I have a TBL file of 11000 items and the IDX is 22000 in size, thus 2 bytes per item.

Could you please update me on the new procedures reading from and writing to the IDX file?

I've already tried reading 2-byte integers, but it doesn't seem to return usable information.

I promise I will try (not certain I can achieve this) to rewrite the program so that it can by used by the general public and make it available to all...


Kind regards,


J Mous

[Dale Harris]

JF Mous,

Whenever you access the stock table (where you can add new items) the program rewrites the .IDX file. This way if any errors creep into the .IDX file they can automatically be fixed. The SUB for doing this is below...

DEFLNG A-Z
SUB FIXIDX (RC)
DIM TB$(14)
ON ERROR GOTO ERRR: KILL PATH$ + FL$ + ".IDX"
CALL OPENS(1, 2, 4, 0, ".IDX", FL$)
FIELD 1, 2 AS PL$
CALL OPENS(2, 120, 1, 0, ".TBL", FL$)
FIELD 2, 46 AS NULL$, 18 AS AA$
ON ERROR GOTO 0
FOR A = 1 TO RC
GET 2, A + 1: A# = VAL(AA$)
IF A# < 1000000000 THEN P = A# ELSE P = VAL(MID$(LTRIM$(STR$(A#)), 3, 9))
LSET PL$ = MKI$(P MOD 65536 - 32768): PUT 1, A
NEXT: CLOSE 2: CALL CLOSES(1, 0, ".IDX", FL$)
END SUB

What happens is that the code reads the stock number from the .TBL file, takes the last 9 digits of the stock number, uses MOD to convert the number to a value from 0 to 65535, and then subtracts 32768 from it. This results in a final value from -32768 to 32767 Which is the allowable range of an interger. Intergers can be stored as 2 byte strings.

So this process reduces a 14 digit number into a 2 byte string, sort of. Since 14 digit numbers are reduced to 65,536 possible intergers it is possible that two or more actual different stock numbers will end up with the same 2 byte string representation. Although the odds against this happening are 65536 to 1 against it for any 2 particular stock numbers. But since there can be 13000 different stock numbers in a stock table if you have a full stock table the odds against a particular 2 byte code matching any other 2 byte code in the entire stock table drop to 5 to 1 against it. This means that it would be a really swell idea that if you do match two 2 byte codes, that you retrieve the actual 14 digit stock numbers from the .TBL file to make sure that they match also.

Remember that in the current stock table file (.TBL) that the first record is now an index and that the first item in the stock table is in record #2. So if the first 2 byte string in the .IDX file is what you are looking for then you must add 1 to to it so that you retrieve record #2 from the .TBL file, if the 500th 2 byte string matches then you must get record #501 from the .TBL file.