Even though my workplace and reduced costs by migrating from Sybase on Solaris to Sybase on redhat. We are now in a move from Sybase to MySQL to further reduce the license costs of the applications. This has brought to forefront one of the reasons to use Sybase. Triggers and stored procedures. And while MySQL now provides both, and transactions in InnoDB engines, Sybase triggers and Procedure are far more advanced. This forms a type of trap, they are very useful, but create serious obstacles to convert triggers that perform Referential Integrity. Just to highlight two types of these issues, take the following;
You can not use ‘select’ criteria in a trigger that returns a value. This prevents executing a select on a table to check for the existence of record prior to an insert/update. This was a major issue with a trigger used to produce a history file via a ‘update’ that had to both insert and update the history table. My workaround was to create a MySQL procedure that had no such restriction, and to call the procedure from the trigger. This worked very well, but of course meant that there was additional overhead and more coding involved.
The second example was, in my opinion, was a far more severe omission of Referential Integrity, ‘Rollback’! You cannot perform a rollback in a trigger. What! Further more, you have use ‘set autocommit=0’ either as a database default, which it is not, by default, set. Or set it during the batch or client operation that you are performing. Twice bad! Again, my solution was to call a procedure that could perform a ‘rollback’ and to ensure that either the developer set autocommit off or to insure that it was set as a database wide option.
As easy as these solutions were, they highlight an omission of functionality that requires addressing in the future development of MySQL.
RW_Jordan@Cork.Ireland 