Invalid statement after ALTER TABLE to fix column not found in event

[Breck_Carter]

...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 stored procedure event failed at runtime with "column not found" because of a FOR loop which referred to the new name of a column in an existing table when, in fact, the table still had the old column name. An ALTER TABLE was run to fix the column name, and the stored procedure event was re-executed, only to fail with "Invalid statement" (see below). The stored procedure event was recompiled and that got rid of the "Invalid statement" error.

If this is expected behavior, the Help should be updated to mention the possibility that a stored procedure an event should be recompiled:

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.

[VolkerBarth]

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...

[VolkerBarth]

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.

[VolkerBarth]

@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?

[Breck_Carter]

@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.

[Breck_Carter]

@Volker: ...so yeah, technically I don't do "recompile" 🙂

[Former Member · Accepted solution]

The most likely cause for the problem described here is that the procedure was still being used by at least one connection when the ALTER TABLE was performed. For example, if the procedure returns a result set and the application cursor had not been closed, then the procedure would still be in use. Once all references to the procedure have completed, the next call will cause the procedure to be "recompiled" automatically.

[VolkerBarth · Accepted solution]

W.r.t. my first comment on the question: So my assumption (ALTER TABLE triggers an automatic recompile of all procedures/functions - at least those not currently used) is generally right?

[Breck_Carter · Accepted solution]

@Bruce: Arrgh! Not only was the procedure not running at the time of the ALTER TABLE, it isn't even a procedure... it is an event! I have fixed the question.

[Former Member · Accepted solution]

@Volker: procedures not currently in use are recompiled immediately when an ALTER TABLE occurs. Those that are in use will be recompiled when they are no longer in use by any connection, and a new call is made.

[Former Member · Accepted solution]

@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.