Timer,Triggers,Locking and Images

Timers

Question
--------
If a timer expires during a long running query when is it
handled ?
Answer
------
The timer will always wait to be handled until the current
operation has been completed. In other words, the query is
completed before the timer is serviced.
Question
--------
If a REPEAT timer expires between a long query, does it
repeat prior to being serviced by a WHEN-TIMER-EXPIRED at
the end of the query or does it wait for servicing before
repeating ?
Answer
------
A repeating timer will never be restarted until after it has
been serviced by an appropriate firing of
WHEN-TIMER-EXPIRED. A simple corollary to that fact is that
no timer can ever exist twice in the "timers to be serviced"
stack.
Trigger

Question
--------
What is the difference between the following triggers :
- Post-Fetch vs. Post_Query
- Post-Forms-Commit vs. Post-Database-Commit
- Pre-Query vs. Pre-Select
Answer
------
A comparison of these triggers follows :
Post-Fetch vs. Post-Query
POST-FETCH fires just after each attempt to fetch records
from the database. Depending on the value of "Array Size"
for the block in question, and how many records are
actually delivered from the database in response to our
request this trigger may fire fewer times.
In contrast, POST-QUERY fires once for *each* record that
is brought from the waiting area (where records first go
after their fetched in a bunch from the database) and
added to the end of the current block's list of records.
Post-Forms-Commit vs. Post-Database-Commit
POST-FORMS-COMMIT is the renamed version of POST-COMMIT
from V3. It fires as the last trigger which is still part
of the current transaction during commit-time processing
(ie before the actual 'COMMIT' has been issued).
The POST-DATABASE-COMMIT triggers fires just after the
'COMMIT' statement is issued by forms to close the current
transaction.
Pre-Query vs. Pre-Select
PRE-QUERY fires just before Forms begins to prepare the
SQL statement that will be required to query the
appropriate records from the database in response to the
query criteria that have been entered into the example
record.
It is the designers last chance to "deposit" query
criteria into the items in the block as if they had been
entered into the example record by the operator.
PRE-SELECT fires after the PRE-QUERY trigger has fired,
and just before the actual, physical construction of the
SELECT statement begins. It would typically be used in
conjunction with an ON-SELECT trigger in which the
designer would be supplanting the normal construction of
the SELECT statement with a user exit of his own to
construct and prepare the SELECT statement for execution
(perhaps against a foreign datasource).

Locking

Question
--------
Is it possible to defer locking of a record until commit
time ?
Answer
------
Yes, in Forms 4.5 there is a block property called 'Locking
Mode', which can be either 'Immediate' or 'Delayed'. If you
set it to 'Delayed', then a record in a block is not locked
until commit-time, specifically until changes are 'posted'.
At that time, the current forms value is compared to the DB
value before issuing the update statement. The user will
get an error if the record has been updated since it was
fetched.
'Locking Mode' can be changed at runtime in a trigger with
the Set_Block_Property builtin.

Images

Questions
--------
How can I get an image from a file to be stored in my
database ?
Answer
------
To store images in the database, you need to read them from
the file system in one of the supported standard file
formats :
'PCX'
'BMP'
READ_IMAGE_FILE('file_name', 'TIFF', 'block.image_item');
'JFIF'
'PICT'
Into an item in the form. Then commit it to the database :
COMMIT_FORM;
Make sure that 'block.image_item' is a database item in a
database block and that the 'image_item' column in the base
table on which the block is based is declared as LONG RAW.