FR: have the errors as an internal errortable

[Ivan Smahin]

Hello Bart,

Monday, September 24, 2007, 12:27:09 PM, you wrote:

> Hi List, Ruslan et all,

> When thinking about errorreporting this weekend I thought I would  
> introduce a feature request to have the errors.xml file available to  
> the engine. This way I could build an ErrorProcedure that started  
> with a select statement, selecting the error txt.
> However as I read my mail this morning I understand that there will  
> be an @@lasterrorid and @@lasterrormessage. So if I understand it  
> this takes care of having to select the errormessage and we can just  
> go ahead and 'print' the errormessage through @@lasterrormessage.

> Did I understand this correct ?

Correct.
Please keep in mind a couple of things:
1.  That  variables  are initialized if some exception is thrown inside
some stored procedure only.

2.  @@LastErrorNumber contains hex value. You can use new sql-function
to show its string representation: HEX

SELECT HEX(@@LastErrorNumber), @@LastErrorMessage;



> Some thoughts about error reporting

> As it stands now there is no way of saying that our errorProcedure  
> should ALWAYS be used, is there ? Maybe I should explain:
> Now we need to explicitly call in an exception block of a stored  
> procedure the errorProcedure in order to trigger it. I think it would
> be better if a developer would be able to specify that the  
> errorProcedure should always be used when an error occurs (not only  
> when called from a stored procedure but also when a query launched  
> through an API generates an error. This way error handling would be  
> as close as possible to the engine and as close as possible to the  
> developer (the one making the mistakes :-)) and logging of what went  
> wrong would be a lot easier.

Add it please as feature request.
I  see  - you want to get something like a hook to register own "event"
handlers. Particularly error handler. Need to think.


> May I suggest that we will be needing an 'inTransaction' variable  
> which it will make it possible to do rollbacks inside the  
> errorprocedure (when transactions will be implemented).This way we  
> will be able to say when an error is handled

> if inTransaction then
>         rollback
> else
> ...

Why  you  need some flag to issue rollBack? You can rollback
transaction at any moment.


> Besides having the @@lasterrorid and the @@lasterrormessage it really
> would like to see the @@lastquery. Again logging the errors together  
> with the querytext will make debugging A LOT easier if the 'guilty'  
> query is shown in the error log.

Also, put it into Mantis please.

> In the previous paragraph I wanted to say 'the ability to store the  
> text of the query or at least the name of the query' when I realised  
> that we don't have 'named queries' in Valentina (we don't do we ?).

Not yet.

> I
> realise that we have views and stored procedures to workaround this  
> limitation but it still feels like named queries (postgresql style  
> (the only one I know)) would be a nice addition to Valentina's  
> toolbox. Maybe I should explain named queries (as I used them):

> Named queries are queries with parameters send to the server on  
> connection level. Something like this:

> prepare namedquery 'query1' as 'SELECT recid,* from tbl1 where recid  
> = ?"

> The server preparses and optimises the query and from then on you can do

> runquery 'query1' with (15).


Actually  there  is  no  much  difference.  In  our  case  the  first
binded-query or SP will take  some  time to be parsed and prepared.
Next time it will be found in the plan's pool.


> The advantage is that for queries that are API dependent (let's say
> we use RB and PHP and the interfaces (and the queries) CAN be quite  
> different) the API can send queries to the server that are cached and
> preparsed so that from then on you have same advantage as when having
> views or stored procedures.

Why don't you just use stored procedure?
Anyway it seems to be a feature request again.


> So monday morning has passed and I am ready for another week of  
> working with Valentina (be afraid, be VERY afraid :-))

We are trembling already :)


-- 
Best regards,
Ivan Smahin 
Senior Software Engineer
Paradigma Software, Inc
Valentina - The Ultra-Fast Database
http://www.valentina-db.com