At 09:43 AM 14/10/2004 +1000, you wrote:

>Unfortunately I did not state this correctly in my previous email fact that
>I had tried with and without it. This can also be said for the
>ColumnAttributes problem I am having when trying to use the
>
>MYTABLE>MYCOLUMN=BOOLEAN

Don't try to make this into C++ syntax. It's a string that is stored in
the TIB_Stringlist and it has a consistent format:

MYTABLE.MYCOLUMN=BOOLEAN=Y,N

>Any help, suggestion, criticism or laughter would be welcome at this stage,
>as I am totally out of ideas regarding what I am doing wrong.

Did you download the file ti_FieldsParams.zip? ("Working with Fields and
Params"?)

>I am now wondering if I should be using a TIB_Query, TIB_Grid combination.
>If possible, could you explain to me when would you use a TIB_Cursor,
>TIB_CursorGrid combination as opposed to using a TIB_Query, TIB_Grid
>combination.

As I said before, I *never* use TIB_CursorGrid. It has the very limited
use of providing a "container" for the rows of an unbuffered dataset. I
use TIB_Cursor a lot, though. One of many uses is to populate a TIB_List or
TIB_ComboBox; in fact, anything at all that I use a TStrings for. I write
functions that refresh these strucutes whenever required; often I will
push e.g. a key into one TStrings and a value into another, and use one
with reference to another. On large sets, the performance is in the range
of 200 to 500 times faster than using Delphi's NAME=VALUE methods. It's
also a very fast way to build (and rebuild) linked lists.

Another way I use TIB_Cursor a lot is to represent a single row for update,
in the course of "drill-down" search-and-update operations, the only right
way to do client/server operations IMO. Because I'm always aiming to get
the user to exactly the right place with the minimum of overhead, I won't
use editable grid interfaces. The final point of a
search-for-a-human-to-update operation is a quick, single-row pull into a
parameterised TIB_Cursor which the user sees as a form or a section of a form.

If you want to see an ib_cursor being used to fill an ib_cursorgrid, look
at the Cursor tab in IB_SQL (or any of the property editors that use this
utility). For example, do a SELECT * FROM ABIGTABLE using this interface
and you will see that it is very slow. This is because the ib_cursor pulls
across exactly one row at a time, in contrast to ib_query, which pulls
across batches of rows, dissects them, and stores them in a number of
client buffers. To "scroll" a non-buffered dataset requires re-fetching
the whole dataset from the beginning, so the ib_cursor/cursorgrid
combination isn't a good choice when you want to implement a responsive
scrolling grid interface.

If you need the buffering (scrolling, smarts about which rows the dataset
wants next, and so on) then use ib_query and ib_grid (and, for goodness'
sake, try to keeps sets as tight as possible with WHERE clauses!). But
don't use tib_query when you don't need a scrolling interface.

>If you require further information regarding what I am trying
>to archive, please let me know so I can provide this details.

Not unless it helps to solve a specific problem that you have.

Helen