Howdy;
I'm writing a "script" to pre-populate a database system that's
already in place. The database system is in an advanced stage of
development and includes many stored procedures and TRIGGERS.
The "script" is really a stored procedure designed to be executed by
the system's admin guy
Thanks Tom. The work-around was to create the "script" in SQL -- using
SELECT INTO statements to capture the key values -- instead of creating
the "script" as a stored procedure.
Seems like a "transaction" issue. Having transactions occur at the SELECT
level is very intuitive and a really nice,
"Martin Crundall" <[EMAIL PROTECTED]> writes:
>Some of the data tables have "AFTER INSERT" TRIGGERs on them that, in
> turn, insert some subordinate items into parallel data tables and the
> central pointer/ordering table.
It looks to me like AFTER triggers are fired upon return to the main
lo
Howdy;
I'm writing a "script" to pre-populate a database system that's
already in place. The database system is in an advanced stage of
development and includes many stored procedures and TRIGGERS.
The "script" is really a stored procedure designed to be executed by
the system's admin guy
