We have a very large table which is about to break 2GB on both the LK and OV files. We have broken it up into a number of smaller tables, with the appropriate sub-table chosen by a hash of the record key. Rather than try to modify every piece of code that touches this table (because there's an terribly large amount), we've decided to put an MFS on the original (root) table that will store the handles of all the sub-tables and forward MFS commands to the handle corresponding to the hashed key.

For MFS commands that access a specific record (READ, WRITE, DELETE, etc), this is working perfectly. But I am running into problems when I try to make a SELECT and READNEXT loop of the root table span all of the subtables. The MFS maintains the sort field, select mode, and select pointer being used, as well as a flag indicating which of the subtables the READNEXT loop is currently working in. When a SELECT or CLEARSELECT comes through, that flag is reset and the select-related variables updated. During the READNEXT processing, if the call to RTP57 READNEXT returns a zero status, then the flag is incremented and a call to RTP57 is made using the next handle and SELECT, and READNEXT processing continues using the new handle and select pointer. READNEXT won't actually return a zero status until the very last file handle has exhausted its list.

This, I think, should work. And in fact it _does_ work. At first. After the first few subtables are exhausted, the SELECT on the next file handle returns a null select pointer, making the ensuing READNEXT think the file simply has nothing in it. It does this for several files and then returns a valid pointer a few times, and then repeats. All told about 1/4th of the tables are actually selected The handles are all valid, and if I change the order in which the subtables are processed, some that were skipped become traversed and vice versa.

Any suggestions?

Without knowing more about the network driver and ARev version, I'd say you may need the occasional flush;garbagecollect command.

The Sprezzatura Group

World Leaders in all Things RevSoft

I'm not entirely sure what I did (I'd thought nothing, but obviously I did _something_), but after trying FLUSH/GARBAGECOLLECT commands between file selects (which had no effect) as well as calling CLEARSELECT (which only got into a recursive loop), the cross-file SELECT is returning all the records it should be.

Now, if I perform SELECT CL01, it returns X records but it also says "1 error(s) were detected" and doesn't clarify what the error(s) actually are. I ran an R/BASIC SELECT/READNEXT loop through the whole file. It encountered no problems, but the number of records found was 1 less than returned by TCL SELECT.

So, what does TCL SELECT mean when it says it finds errors like that?

Do you mean B802 message? You may wish to check out this thread out.

View this thread on the forum...