Hello all -

We're working on an integration project with Timberline where we want
transactions to be "exported" in real-time. Currently, data is exported via
a nightly batch job, but the ultimate goal is to create a
real-time/transactional solution.

Our thought is to create a staging table in Btrieve. Whenever a record on a
specific table in Btrieve is created, a trigger will fire to insert a record
into this staging table. Then we'll have a separate application which
constantly "polls" (ie does selects & deletes) this DB.

Are these triggers feasible in Btrieve? Are there any limitations with any
versions of Btrieve that will prohibit this? Overall, does this solution
sound feasible?

I appreciate any and all advice!

Thanks,

Josh

Josh wrote:
Not at the Btrieve level. If you're accessing the data via Pervasive.SQL
then you can use SQL triggers. These are implemented in the SQL system
which 'sits on top' of the btrieve system. Pervasive SQL triggers can be
used to update a second Pervasive.SQL table when updates occur on another.

It would be feasible for the program reading the staging table to read and
delete at the btrieve level because it does not need triggers. However the
program that puts data in the 'specific table' will have to do so using
Pervasive.SQL if you want triggers to work.

Here's a little hack...

Create the staging table using Pervasive.SQL and create an update trigger.
Define the staging table with an extra status flag.

Insert new records into the staging table using btrieve, set a status flag to 1

At intervals run a Pervasive.SQL update to set the status flag to 0.

The Pervasive.SQL update will fire (pull?) the trigger and copy the data to
the staging table.

See above!

In Btrieve, no. In Pervasive.SQL, yes.

This is USENET... Do you really mean that! :-)

Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk