Thanks, Tore.

>First of all, the line number reported must not necessarily be the line number you count, but the line number if you ignore blank lines, memo lines and continuation lines.

I disagree. In the prog editor you tell it to go to line x and that's the line it goes to, regardless of blank lines etc. This has always been the case for me. It wouldn't be very useful if you had to guess what offset the report was using. Besides, it went to the same empty line originally. There have been changes made to the .prg since the last exe but, after recompile, the same line had the error.

Notwithstanding, as this line is in amongst the lines that open all the tables for the prog, I did try many of the lines around it (where an order clause was included in the USE) but no other table gave me this error.

>
>For the error itself, IIguess you have an index key which does not give a fixed length key. Personally I had this problem myself for a long time, the index key was str(10000-myvalue,4). This worked fine until myvalue one day had a value of 0, then the result was 10000 and str(..,4) was too short. I fixed it by changing my index expression into str(9999-myvalue,4).

The index is on the date field. Again, like i say, this is used extensively, often, in other dirs too (with another copy of the exe).

Cheers

Terry

>
>>Thanks Al
>>
>>No I don't think that's the case. You see, this suite of progs has been in use since the early 90s. There is a copy of it in each folder dedicated to a particular customer (don't ask - I know!), so every customer has its own set of tables, and there's the exe in each folder too. It always has worked in this folder, for this customer, adn the suite works fine in all the oter customers' folders.
>>Default is set to the current dir of the exe so no awkward paths to other places.
>>The CDX WAS there before I modi stru'd and disappeared it. AQs I said, I recreated the index anyway, and it's there for all to see, so the error shouldn't happen now - IF IT IS THAT TABE!!!
>>
>>I'm only assuming it's that table anyway cos, as I pointed out, the error is reported on a white space line anyway!
>>
>>Beats the HELL out of me!
>>
>>
>>>Only thing that comes to mind is that since you couldn't find the cdx but the error suggests it's in use and the fact that you reindexed, maybe the program isn't using the set of tables that you think it's using. I've had that happen more than once.
>>>
>>>>Hi guys
>>>>
>>>>This old fpd26 system I have to maintain. It has been working fine then suddenly the user got an error:
>>>>
>>>>Index does not match the table. Delete the index file and re-create the index (Error 114)
>>>>
>>>>at line 69.
>>>>
>>>>Now line 69 had nowt in it but there have been changes to the prog since the last compliation so I couldn't trust that.
>>>>So I recompiled the prog and ran it. Now the error's on line 72 which is:
>>>>
>>>>

>>>>sele 0
>>>>use bankhols order 1
>>>><--------------------------- line 72
>>>>sele 0
>>>>use xvalue
>>>>

>>>>
>>>>the same line as before!!!!!!
>>>>
>>>>So obviously the table bankhols was suspect. But I ran the same line "use bankhols order 1" in the IDE and got up the table OK.
>>>>Using modi stru (in FPD26) I disappeared the little up-arrow next to the Date field in this table, the indexed one, to get rid of the index.
>>>>I was going to physically delete the .cdx in explorer but this action seems to have done it for me (I couldn't find the .cdx).
>>>>Then I put the arrow back in to create the index and saved. The usual "x records indexed" message came up and the up-to-date cdx file was there in Explorer.
>>>>I opened the table in the same way and browsed it OK.
>>>>Closed the table and ran the system again
>>>>
>>>>Got the same error.
>>>>
>>>>Anyone got a clue what's going on here? PS I did open and browse all the tables USEd around this line just to make sure it wasn't one of them.
>>>>
>>>>'ppreciate it
>>>>
>>>>Terry