Revision Date: March 14, 2000
Working with Cursors
This tab is used in processing SELECT statements that are for selecting multiple records in a unidirectional fashion.
After a statement is Prepared this tab will show the query Plan assigned to it by the InterBase compiler. This is a great feature to be able to see how InterBase is or isn't optimizing your statement.
Searching a Dataset
The IB_SearchBar provides a way to turn data entry fields into search criteria providers.
It allows a dataset to have QBE search criteria entered to narrow down the number of records retrieved from it. The button with the blue question mark on it initiates the dssSearch mode. Then, QBE criteria entered into the data entry fields can be saved, cleared and restored by using the other buttons. The data-entry fields are located in the sub-tab "Search".
The SIGMA button is used to perform a count of how many records meet the search criteria entered. If no search criterion is entered then a count of all records for the dataset is returned.
The search criteria is taken and appended to the WHERE clause of the SELECT statement entered the SQL tab. It may be helpful for you to turn on the trace monitor and see what statements are being generated for you when using the built-in search features.
For a detailed explanation of how to enter valid QBE criterion, please see the section dedicated to it below.
Navigating a Cursor
IB_NavigationBar is used to move through the records selected from the dataset.
There is no Prior button because InterBase cursors are only unidirectional. There is no built-in buffering in the dataset either.
First opens a new cursor and the first record of the dataset is retrieved. If a cursor was already opened it will be closed before the new cursor is opened. Last takes you to Eof.
On a large dataset, if Last is clicked there should be a dialog presented giving a count of the number of records fetched. In addition, a button allows you to abort the process of fetching all records of the dataset. This can save a bad problem from happening that would cause you to have to END-TASK or wait quite awhile until all records have been fetched.
NOTE: Only records that match the QBE search criteria entered while in dssSearch mode will be processed.
Inserting, Editing and Deleting with Cursors
IB_UpdateBar is for managing modifications to a dataset.
There are color contexts to help reflect what action is being taken. When in dssEdit mode, the Post and Cancel buttons are yellow; when in dssInsert mode they are green; when in dssDelete mode they are red.
NOTE: Be sure to include the FOR UPDATE clause on your SELECT statement if you intend to make and edits or deletes to your cursor.
The IB_TransactionBar allows you to Rollback or Commit changes and is here for convenience only.
Defining a Cursor SELECT Statement
The SQL tab is where you enter in the SELECT statement. Refer to InterBase documentation for the full syntax allowed.
Specific to IB Objects is how named input parameters are handled. You can name a parameter simply by appending it to the '?' that denotes the parameter. In Delphi the ':' character is used which also works in InterBase Objects. If you put a '?' or ':' without an identifier then a default name is assigned to your parameter.
If your statement includes a parameter, prepare it and then confirm by looking at the tab for Params.
The Params tab, as mentioned, is for setting and displaying input parameters of your SELECT statement. After having prepared the SELECT statement, you can enter parameter values for them in this tab.
The Fields tab gives a detailed description of each output column defined by your SELECT statement.
The Search tab is a set of dynamically created IB_Edit fields for entering in QBE search criteria. They are also used for inserting and editing column data.
There is an explanation of how the QBE search criteria works and its syntax in a section later on in this help file.
The Data tab has a read-only grid that acts as a buffer of each record as it is fetched. It is not like the DBGrid that demands to fill in as soon as the statement is opened. This grid waits until records are fetched and then it displays them.
This is very useful since it can be scrolled and columns widths are sizable. Since it is a TStringGrid descendent it is NOT efficient with memory and doesn't perform very well so don't use this Cursor tab to test big long queries. You will run out of memory and it will take forever. Using an IB_Cursor component without this string grid attached is ideal for use in your apps so please use it when efficiency and performance is concerned.