I am trying to automate a process that would otherwise require users to
click a button to 'compile' information from one table (formulas) based
on info entered in a workorder (images) and update another table
(colors).  This is very important, I'd rather not rely on users
remembering to do that.  So I added triggers to the images table.  The
triggers run stored procedures that declare a cursor on a VIEW that
contains the table that has the trigger (confused?).  I don't know if
that is a problem or not - it works like I want it to, but now I'm
seeing something not so good.  

In another part of the program, I'm inserting rows into this images
table through code (INSERT INTO TABLENAME (COLUMNS) SELECT COLUMNS FRO
ANOTHER TABLE WHERE COLUMN = VARIABLE).  With multi set on, the insert
works, but I get an error message saying "Internal lock error.  Have all
users disconnect from the database.  Then have on user re-connect."
Which of course, I immediately do. (This is a test copy, I'm not really
concerned about anyone else using it.) If I connect with multi off, I do
not get that message, but the program hangs on a declare cursor (on that
table) a few lines down from the insert.  I reloaded, etc with no
results.  I suspected the triggers were the issue so I removed the
triggers from the table, and voila no errors. So...is it not a good idea
to trigger a cursor on a view that contains the table that has the
trigger? (I feel like I've read that in a Dr. Seuss book!)  Or is that
OK, and I have a different problem?

Dawn

Reply via email to