jbart
Oct 4th, 2000, 07:01 AM
Just curious if anyone else has run across this situation.
I use the recordset.Update command to update a table on a SQL Server. One of the fields is a trigger field.
The Update command from VB is taking control of the SQL trigger process and will not continue until that trigger is completed. Also, there is a command in the SQL trigger that sends an e-mail to another SQL database. After working with this problem for a day, we finally found that setting update permissions for the e-mail command allowed everything to work correctly. Without setting the permissions, the update command would execute but none of the fields in the table would be updated.
Also, the SQL trigger had Print commands in it to use for debugging on the SQL side. VB was treating these Print commands as Run Time Errors.
Is it normal for VB to take control of the entire SQL trigger ?
Thanks for any feedback.
I use the recordset.Update command to update a table on a SQL Server. One of the fields is a trigger field.
The Update command from VB is taking control of the SQL trigger process and will not continue until that trigger is completed. Also, there is a command in the SQL trigger that sends an e-mail to another SQL database. After working with this problem for a day, we finally found that setting update permissions for the e-mail command allowed everything to work correctly. Without setting the permissions, the update command would execute but none of the fields in the table would be updated.
Also, the SQL trigger had Print commands in it to use for debugging on the SQL side. VB was treating these Print commands as Run Time Errors.
Is it normal for VB to take control of the entire SQL trigger ?
Thanks for any feedback.