FR: have the errors as an internal errortable

[Bart Pietercil]

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 ?


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.


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


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.

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

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.

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

Bart Pietercil