M
Marc Fellman
Guest
OE 10.2b on Linux. I have a procedure that creates a temp-table and that is generating a dynamic query to go through that temp-table. All works fine except..... One of those temp-table records ended up empty (was in it self correct, based on data in the database) and Progress stopped! It was using a for each where one of the first statements was to test on entry 2 of a field in that temp-table. It complaint that "entry 2 is outside of the range of " (an empty string). That feels odd to me since there is no real way to add a no-error or something like that to a query. So I tested it on a small program (to see if it is progress or something in my code): DEFINE TEMP-TABLE tt FIELD f1 AS CHARACTER FIELD f2 AS CHARACTER. CREATE tt. ASSIGN f1 = "A-A" f2 = "1". CREATE tt. ASSIGN f1 = "A" f2 = "2". CREATE tt. ASSIGN f1 = "A-C" f2 = "3". FOR EACH tt WHERE ENTRY(2,f1,"-") EQ "A": DISPLAY tt. END. This one fails as well (same error). I would have expected it to show only 2 records and work fine. In fixed queries it is no real problem to add a test on the number of entries just in front of the "entry(2" part but because the query I use is dynamically generated it is a lot harder to control the order of tests in the for each. I would expect that progress just left the records out of the result set that do not satisfy the query but for some reason they seem to be in the (initial) resultset and are validated within the execution of the for each. It feels hard to describe 
I guess it is primarily me expecting to much of progress (it is also because some bug did not populate the data in the database correctly that this showed up). I will try to work on the query builder to work around this but it might be hard to make this "FOOL"-proof since this is somehow a free form query (up to special users). I guess the part that is harder is the fact that a "FIND" has a "NO-ERROR" possibility but that is lacking in the "FOR EACH" (not even looking at the dynamic query)..
Continue reading...
I guess it is primarily me expecting to much of progress (it is also because some bug did not populate the data in the database correctly that this showed up). I will try to work on the query builder to work around this but it might be hard to make this "FOOL"-proof since this is somehow a free form query (up to special users). I guess the part that is harder is the fact that a "FIND" has a "NO-ERROR" possibility but that is lacking in the "FOR EACH" (not even looking at the dynamic query)..Continue reading...