In IBO you have a choice of a number of dataset components to choose from.
The native IBO datasets are TIB_Cursor and TIB_Query. The TDataset derived components are TIBOQuery and TIBOTable.
The first decision to make is if any multi-record controls (like a grid) need to be bound to the dataset and if it needs to be bidirectionally scrollable. If neither of these are necessary then the TIB_Cursor is the best bet. It is the fastest and most efficient way to process a query.
Example cases where this component is most appropriate is for exporting data, running a report of some kind, populating a stringlist with values, pumping data from one database or table to another, etc.
It does not maintain a buffer of all records fetched but instead only keeps the current record in memory. In this way it is possible to process millions of records without running out of memory on your workstation.
It is possible to bind this component to native IBO controls like the TIB_Edit, TIB_CheckBox, TIB_RadioGroup, etc.
There is a specialized grid control just for this component called the TIB_CursorGrid. It is really just a derivitave of the TStringGrid such that the internal stringlists act as the buffer for the data that is fetched from the cursor. The grid is very lacking in functionality and control. It is not really intended to be used in applications that demand a lot of customizations, etc. It uses a LOT more memory to buffer a large dataset than does a buffered dataset and a TIB_Grid combination.
This component is a highly specialized derivitave of unidirectional cursors and in-memory buffering techniques that deliver a fully scrollable and buffered dataset. It is the ideal component to develop user interfaces with where the user will be browsing through potentially many records.
Use this component if you do not need TDataset comaptibility in order to use standard data aware controls and would like to take advantage of the special features of the native suite of visual controls in IBO. Most notably is the searching and global focusing capabilities as well as the dynamic SQL binding.
It is a requirement to use this dataset to use controls like the TIB_Grid and TIB_CtrlGrid.
Use this component if you need to maintain compatibility with the standard data aware controls, report writers, etc. It is virtually identical to TQuery in functionality and behavior. Everything including CachedUpdates is supported.
As far as performance is concerned you can expect it to be slighly slower than the TIB_Query since there is an additional layer of buffers being maintained. But, this difference in performance is very marginal. Especially on high-end workstations.
This may seem strange to some but I have built many of the TTable specific behaviors into this component like SetRange, SetKey, FindKey, GotoKey, etc. So, it is possible to have much of TTable's functionality but the control and flexibility of a TQuery.
This component is ideally suited for applications that are being converted from the BDE to IBO and there are TTable components in the application. If you liked working with the TTable component because it does make a few thngs easier then this one is for you. Again, everything including CachedUpdates and IndexDefs are supported.
This component is based on exactly the same class that the TIBOQuery is so there is no difference in basic performance between the two. Because of this I recommend that you use the TIBOQuery component wherever possible so that only the fields which are necessary will be used instead of every single field in the table being returned to the client. You just surrender control by using this component instead of the TIBOQuery component.
If you install the IPIBDataset.pas unit you will additionally have two more components to choose from. They are simply the same as the TIBOQuery and TIBOTable components but with the necessary IP template applied in a sub-class so that their special functionality can be realized. These components are TwwIBOQuery and TwwIBOTable.