...and the answer is, from Bruce's comment on his original answer: "@Breck: there is currently no mechanism for automatically recompiling events. You can, of course, put the logic for the event in a procedure which the event calls. – Bruce Hay" Here's the scenario in 11.0.1.2276: An updated If this is expected behavior, the Help should be updated to mention the possibility that http://dcx.sybase.com/index.html#1101en/saerrors_en11/errm130.html Invalid statement Error constant SQLE_INVALID_STATEMENT ODBC 2 State ERROR ODBC 3 State ERROR Severity 16 SQLCODE –130 SQLSTATE 07W02 Sybase error code 13628 Probable cause The statement identifier generated by a PREPARE passed to the database for a further operation is invalid. |
According to the discussion on http://sqlanywhere-forum.sap.com/questions/1226, I would have expected that ALTER TABLE causes all STPs to be recompiled - not sure if there's a misunderstanding on my part or why it hasn't happened here...
Having said that, the help for ALTER PROCEDURE (http://dcx.sybase.com/index.html#1200en/dbreference/alter-procedure-statement.html) implies that RECOMPILE "can be useful if a table referenced by the procedure has been altered to add, remove, or rename columns since the procedure was created." - Yes, I'm puzzled.
@Breck: How exactly do you recompile an event handler (as there is no ALTER EVENT RECOMPILE clause, AFAIK)? ALTER EVENT with the original event handler?
@Volker: I'm old school, every [module].SQL file contains a DROP and CREATE. The DROP is wrapped in a BEGIN with an empty EXCEPTION WHEN OTHERS THEN so it doesn't throw an error on first execution.
@Volker: ...so yeah, technically I don't do "recompile" :)