At 08:26 AM 12/10/2004 +1000, you wrote:

>Hi,
>I am not sure if this email made it to the group yesterday, as I did not see
>any activity in the group for the entire day.

It did; and there were several messages after it.
As an observation, you really can't expect an "instant reply" to a message
like yours - which contains multiple issues - you would be lucky to get any
kind of quick answer when a complex reply is needed.

You wrote:

>To familiarise myself with IBObjects, I am writing a very simple application
>that will allow users to Search, Edit and Insert records on a single table
>in a DB.
>
>I also decided to use data-aware controls for Search, and Edit using a
>TIB_Cursor combined with a TIB_CursorGrid. For insertion I have setup a
>TIB_Query combined with TIB_Edit components.

You do not need to have both. TIB_Cursor and TIB_Query both return
datasets. The TIB_Cursor returns an unbuffered dataset, which means you
can't scroll through it. It is a very useful thing to use, once you
understand the "mechanics", but it might be simpler for a beginner to start
with TIB_Query.

>The application has a DataModule which contains:
>
> TIB_Connection
> TIB_Transaction
> TIB_Cursor with a TIB_DataSource (The DataSet property is the
>TIB_Cursor) and a TIB_CursorGrid
> TIB_Query with a TIB_DataSource (The DataSet property is the
>TIB_Query)

You need to link these components up to one another. The transaction
object has the IB_Connection property to link it to the connection. The
dataset components have both IB_Connection and IB_Transaction properties to
link them with both.

>My question is regarding the insertion of new records into the single Table
>of the DB using the TIB_Edit components through the TIB_Query.
>
>I have set up the DataSource property (to point to the correct
>TIB_DataSource, as well as a the DataField property of the TIB_Edit to point
>to the field(s) of the DB table.
>
>In the TIB_Query - SQL - UpdateSQL - InsertSQL I have defined the following
>SQL statement:
> INSERT INTO LOGPAS(
> R_CREATED_BY,
> R_LOGIN,
> R_PASSWORD,
> R_URL,
> R_SHARED,
> R_PRIMARY,
> R_SECONDARY,
> R_COMMENTS)
>VALUES (
> :R_CREATED_BY,
> :R_LOGIN,
> :R_PASSWORD,
> :R_URL,
> :R_SHARED,
> :R_PRIMARY,
> :R_SECONDARY,
> :R_COMMENTS)
>
>
>I have set all the properties of the TIB_Edit components to allow for
>insertion. However, when I run the application, I am NOT able to
>place/write/insert data into the TIB_Edit component fields, as they appear
>to be ReadOnly.

A basic essential with IBO datasets is to set the KeyLinks property. On a
single-table query, this is usually the columns of the primary key. In the
simple case, you can set KeyLinksAutoDefine and let IBO find the key
columns itself the first time it prepares the query. In practice, I
always set the KeyLinks explicitly.

In a single-table query, you don't need to set the XXXSQL
properties. Instead, set RequestLive to true and simply call the method.

You can use the XXXSQL properties for mixed-table datasets and other
"non-updatable" selects, usually to call executable procedures, to get
"live" datasets for these queries.

>However, I have triple check to ensure that all appropriate
>properties and flags as set so that insertion of data is allowed.

It won't be updatable without KeyLinks.

>My main ambition is to learn how to correctly use this package, as opposed
>to getting the application to just work. Thus I would like to know what is
>the "Correct" way to insert records into a table with in a DB.
>
> (1) Should I use Data-aware components? Or just use the standard VCL Edit
>components with code susch as:
>
> DataModule->TIB_Query->FieldByName("FIELD_NAME")->AsString =
>FVariable;

Data-aware controls are fine. While it is quite valid to write apps that
don't use data-aware components, there is a lot of functionality
encapsulated in data-aware controls that you would otherwise have to code
yourself.

The dataset-driven interface emulates a "positioned update". That is, it
targets the current row and posts an update or delete to the exact row
whose Keylinks uniquely identify it in the underlying database table. In
the case of inserts, the KeyLinks must be able to provide the unique values
for the key.

> (2) Should I be using the TIB_Query - SQL - UpdateSQL - InsertSQL
>functionality?

In the common case, you don't need to. The "standard" way for a dataset to
respond to DML calls is to set up the XXXXXSql statement automatically,
creating a parameterised statement with parameters based on the dataset
columns and a WHERE clause based on the KeyLinks.

But it's available and highly powerful when you need to perform positioned
DML differently to the standard way. It makes it possible then to write
SPs to update multiple tables from a joined set; or to "update" the output
of a selectable SP.

Helen