One thing to keep in mind: Unless the SQL Extension has been changed since the last time I looked at it, it did _not_ fully implement our Document Table Model (DTM) API. The most essential diference was that -- like some other database accessors -- it was a one-time operation; you could move forward through the returned data, but NOT backward, since each step forward might overwrite storage used for previously returned data. That's very efficient when you've got a lot of data to walk through... but it would mean that pre-scanning data to build keys simply would not work, since the data would be discarded after being scanned. and unavailable for later retrieval.
If that's what's happening, one workaround might be to copy the data returned by the SQL Extension into a new Result Tree Fragment. This would allow full random access to the data... but would give up the storage optimization achieved by reusing the same buffers. Longer-term: Should the SQL Extension offer a mode in which it _does_ build a complete in-memory DTM? ______________________________________ Joe Kesselman / IBM Research
