Steve wrote:

> ... As you can imagine the view is slow either way. I am
> trying to see if having 31 different TIB_Querys is better
> than having a single huge query record. ...

Current versions of IBO can be quite slow on a query that has
a very large number of fields, particularly if you use (as I
do) IB_Connection.FieldEntryTypes := [fetDomainName]. Certain
versions of various report writers have also had problems with
queries with large numbers of fields because they did (do?)
things by field name rather than by index.

When I read Ed's reply to your problem, with the possibility
that you could "move the data into a local storage container",
it occurred to me that you have a third possible solution:
Write a stored procedure in your database that returns 10
records of 31 fields. Call that from a TIB_Cursor and cycle
through to load your local storage. This would almost
certainly be faster than either of 1 query of 310 fields or
31 queries of 10 fields.

Note: The curious thing here is that inside a stored procedure
you can, IF the data-types permit, turn the data sideways and
return either 10 records of 31 fields, or 31 records of 10
fields, depending on what fits better at the client. This
approach could conceivably allow you to use TIB_Query and show
results inside TIB_Grid or similar if desired. You would
presumably have to write insert/edit/delete procedures to
handle any editing you want to support.

(I hope that's clear enough.)

--
Geoff Worboys
Telesis Computing