Field x is no longer in file y

[DaveK_(Guest)]

Lately we have been encountering an error where R&R reports that a field is missing from a particular table, yet it is a field that never was in that table (it is a field used in other reports in our application). Anyone have any idea as to what could be causing this. Restarting the program normally corrects the problem (at least temporarily). ____Thanks

[kfleming]

What version of R&R are you using?____Kathleen__R&R Support

[DaveK_(Guest)]

Sorry for the delay in replying. We are using ver. 8. A little more information about the problem: The dbf file named in the error message is not a table used in the report, the field is but it is in a different table. We have been able to trace the error to the following line in our program (in Borland C++ builder 5 using the OCX)____ RRReport1->RelatedTables[1] = newPath;____When this line is executed the next time the user tries to run the report the error occurs. if we change the array index to between 2 & 8 the error doesn^t occur, so this solves our problem, even though in the report designer the relation we are overriding is the 2nd one listed (hence the array index of 1). Is there something we might be doing incorrectly?__Thanks__

[kfleming]

It sounds like a bug so your workaround of using a array value is the right thing to do. There does not need to be a correspondence between which relation you override and which array number you select since R&R uses the alias name to know which relation to change.____Kathleen__R&R Support

[DaveK_(Guest)]

Actually testing today on a customer machine has unfortunately shown that our workaround only works on our development machine, I assume because R&R is finding and using the paths to the tables that were saved with the report when we override the related table with an invalid array index on the development machine. On customer machines this workaround does not work. Some additional information:__- the line of code we traced the error to is executed when our program starts to set the startup paths (which I hadn^t noticed & therefore didn^t mention when I made the original post about this), and it does not cause any problem. The error only occurs if the line is executed a second time, and then the error always happens. Other relations in the report can be overridden multiple times without causing a problem. Fortunately in our program this line is only executed a second time if the user changes the paths to tables on a different machine, which doesn^t happen often, and so as a workaround we can shut the progam down and restart it (with a friendly message to the user) when the paths need to be changed (Incidentally you do have to use the correct array index it seems or the relation can^t even be overridden the first time). The actual relation as shown in the report designer:____lookup(Mastertable->linkfield, Relaatedtable : TAGNAME, 12 chars, skip)____The only difference we can see between this relation that causes a problem and the others that don^t is the partial length linking field.____It does seem as if there is a problem with the RelatedTables implementation, as this is the second time we have run into a problem with it. The first time we found it could not handle UNC paths consistently, most of the time it would work without a problem, but then every once in a while a report would fail with an error message like "Cannot open database table T.DBF", where T would be the first letter in the alias name, not the first letter in the UNC path to the table. The workaround that time was to use mapped drives instead of UNC paths, which complicates installations but does seem to work.__(BTW the line of code I listed in the previous post should have read __RRReport1->RelatedTables[1] = newPath; __sorry if this caused any confusion)__Thanks

[kfleming]

I will see if I can reproduce this based on the additional info.__However I will not be able to do so until I return from vacation on next Tuesday.____Kathleen__R&R Support