Why does this sybase error disappear with any request change?

Question

The query that I used for many years suddenly began to throw a strange error. When I made a cosmetic change to the request (1 + x instead of x + 1), the error no longer occurs. The saved process of which he complains no longer exists on the server!

I am very curious if anyone has any ideas on what the problem is and why this “change” corrects this?

Request before:

UPDATE SOME_DB..JOB_QUEUE SET ERROR_COUNT = ERROR_COUNT + 1, JOB_START_TIME = '{1}' WHERE JOB_ID = {0} 

Request after:

 UPDATE SOME_DB..JOB_QUEUE SET ERROR_COUNT = 1 + ERROR_COUNT, JOB_START_TIME = '{1}' WHERE JOB_ID = {0} 

The error it throws is:

 Sybase.Data.AseClient.AseException: Procedure sp_net_dblatency expects parameter @heartbeat, which was not supplied. 

I was wondering if anyone has any ideas what is going on here?

Edit This is where proc is stored.

 create procedure sp_net_dblatency @heartbeat datetime as update DATABASE_1234..LATENCY set START_UTC_TIME=@heartbeat, END_UTC_TIME=getutcdate() where DATABASE_NAME=db_name() if (@@ROWCOUNT = 0) insert DATABASE_1234..LATENCY (DATABASE_NAME, START_UTC_TIME, END_UTC_TIME) values (db_name(), @heartbeat, getutcdate()) 

Answer 1

The Sybase optimizer can cache a plan that erroneously references a remote procedure. It draws attention to history and caches all kinds of statistics and generates plans based on a lot of cached information. Sometimes I find that he can start creating very bad plans for very large requests. I came across this several times and reported it as a bug for Sybase, but they could not reproduce it (and I could not reproduce it reliably).

The workaround is to either slightly modify the request, or add a plan statement to override the erroneous plans. Requests with PLAN operators will use the provided plan instead of creating it. Hope this helps.