> from a previous discussion, I was told that there is no way to trace
> embedded SQL statements of stored procedure / trigger.
True
> While this is true for regular DML statements, stored procedures calling
> other procedures result in additional EXECUTE_PROCEDURE_* events, so I'm
> able to get a stack trace of called stored procedures inside other SPs.
>
> What I don't see at all is I/O statistics at SP level in the trace
> output. Is there a technical reason behind that? Of course, I see the
> various I/O stats at EXECUTE_STATEMENT_* level running e.g. a "execute
> procedure ..." call.
It should be there, i'll check it
> I wonder if there are any ideas/plans on improving the usefulness of
> tracing PSQL modules via the Trace API?
There is idea to add trace event for every point at PSQL module which was
recognized by parser as start of some statement (the line numbers available
at debug info\call stack). Also there is idea to implement built-in functions
which will put some user defined message into trace output.
Do you have own ideas ? Welcome ;)
Regards,
Vlad
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
