Tore

>>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.
>
>Please forgive my not perfect English, I will try to explain better. When I open a program (Modi Prog),

I presume you mean modi comm?

>right-click and choose Go to line, the cursor moves to the line I specify, blank or not. But when you get an error message, error whatever in line x, x is calculated as I wrote, namely by ignoring blank lines, memo lines and continuation lines.

No this is what I thought you were saying.
I'm beginning to doubt my sanity now cos I'm sure it's always been error at line x, and go to line x, are the same. It would be a p!ss-poor error reporter that had you work out the offset yourself. What if the error were at line 1057 and you had to sctroll through the code, ignoring all the non-prog lines, keeping a mental count of what line you're on? Then you get distracted and/or forget your count?

Now, continuation lines maybe! But i still don't think so. Anyway, line 72 has only 1 continuation line of code above it, so that would still bring us to one of teh 2 tables in my illustration.
Going by your word the error would be somewhere in the following lines (then how can anyone be sure!?)

erase looptemp.dbf
release all
return

which wouldn't give an index 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).
>
>Are you sure that you don't have an illegal value in a record? FPD could be somewhat "forgiving".....!
>
>>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