At 05:15 PM 21/07/2005 +0000, you wrote:

>Hi All,
>
>I have a table that has default values on some of the fields
>(specifically dates). There are two views splitting the table "in
>half", one for use by the "originator" and one for the "responder".
>Using IBO V 4.5, TIBO strain database, query and transactions (one
>each of the last two for each view).
>On inserting into the table via the views, the default values of the
>table fields are not inserted - whether or not these fields are
>included in the view being inserted. These date fields BTW are
>intended
>as "origination date" - the day the record was inserted - and "last
>updated" - the date the record was last edited, and are thus not
>entered by the user per se.
>The TIBO components are pretty much set up in their 'basic' modes
>(default values).
>Am I missing a property setting somewhere in one of the IBO
>components or is this the default behaviour of Firebird and would
>have to coded into the "Before Insert" trigger?

No, this is not an IBO issue. It has to do with the characteristics of the
view - including whether it is naturally updatable, or is a non-updatable
view that is made updatable by way of triggers. That in turn, has to do
with the version of server you are using. Without going into enormous
detail....IB 6 was released with serious bugs in the updating of
views. That got fixed in Firebird 1, in the sense of making the behaviour
more predictable.

Then, in Firebird 1.5, it got fixed again to make it so that a
non-updatable view that was made updatable by triggers would cause any
triggers (including the system triggers created for constraints) on the
underlying tables to be ignored. It has been twiddled and tweaked since Fb
1.5, as well.

If you are using InterBase, I have no idea what, if any, fixes have been
done in there for the original bugs; other than the fact that Borland
harvested a lot of Firebird's bugfixes for IB 6.5.

The only way you're going to know what is the expected behaviour for the
version of server you are using is to track down where your particular
version is at. If you are using Firebird, you can track it through the
releasenotes - all of them leading up to the release version you are using.

On the IBO side, you can bypass all of this cross-version confusion and
inconsistency by not activating RequestLive=true on the iboqueries over the
views but, instead, writing custom xxxSQL to that performs DML on the table
directly. If your views have different fieldnames from the underlying
tables, then you will have to write executable stored procedures to achieve
this.

Also make certain that your Keylinks for the views are spot-on.

Another thing to be well aware of - regardless of whether your queries are
over views or tables - is that server defaults kick in ONLY on inserts and
ONLY if the field in question is not in the INSERT statement. IBO will
complain about missing values for non-nullable fields only if said fields
are in the SELECT statement. You can apply FieldsDefaultValues to those
fields to have them applied to inserts. Any values that you want applied
by database defaults or triggers should be omitted from the SELECT and
custom DML statements.

Helen