Funny part is that a Prepare does not give an error, while an execute says Prepare error.
You wrote to ask
That depends on the error, I'd think. I used to teach -- as a general rule of thumb -- that for SQL errors for specific SAL code, like a "non-unique key" error on an insert, etc. you'd trap that locally with When SqlError so you could allow for retries if that was appropriate. For general-type errors, like an Invalid Connection error and so on, you'd trap that globally and use On SAM_SqlError.What's the most convenient way to trap Sql errors?
You also wrote that the
That's odd. Are you sure you have a separate a When SqlError above the If SqlPrepare? And if that succeeds, a separate When SqlError above the (I'd guess next Sql line) If SqlExecute?Funny part is that a Prepare does not give an error, while an execute says Prepare error.
I'd think that if you "seLLect <something>..." (with 2 'L's) that the DB compiler would throw an "invalid syntax" or similar error on the SqlPrepare. Or maybe it depends on the DB brand at that backend??
Palm Springs, California
TD info. & samples: http://www.jeffluther.net/TD/
AFAIK our only option is "When SQLError" for now and I don't know if any improvements are planned in this area.
I do have a global function that is called to log an SQL Error, but still need to use the When SQL clause.
Regarding this, how do you return an error to the client from the operation?
If there is no "when sql", the client gets informed by an ugly looking error, but if I catch it - it doesn't and I didn't find a way to throw my own message to the client.
Who is online
Users browsing this forum: [Ccbot] and 0 guests