On Mon, Oct 1, 2012 at 2:12 AM, Staffan Tylen <staffan.ty...@gmail.com> wrote: > I wonder if there is any trace facility in ooSQLite similar to the > SQLVARIABLE(DEBUG) function in Rexx/SQL. I've seen the trace > method/oosqltrace function in the documentation and understand that they > provide an interface to the sqlite_() API but am not sure how to use it and > what it actually does. Any help is appreciated.
I don't know anything about Rexx/SQL, so whether trace() is similar or not, I have no idea. Here is the doc for trace, it it doesn't word wrap it should be useful: /** ooSQLiteConnection::trace() * * Registers an user callback method used for tracing. * * @param callbackObj [required] An instantiated object with a method that * is invoked at various times when an SQL statement is * being run by ooSQLiteStmt::step(). The callback is * invoked with a UTF-8 rendering of the SQL statement * text as the statement first begins executing. * Additional callbacks might occur as each triggered * subprogram is entered. * * This argument can also be .nil to indicate that any * installed callback is to be removed. * * @param mthName [optional] The method name that will be invoked during * a call back. By default, the method invoked will be * traceCallback(). However, the user can specify an * alternative method if desired. This argument is * ignored when the callbackObj argument is .nil. * * @param userData [optional] This can be any Rexx object the user * desires. The object will be sent as the second argument * to the trace callback method when it is invoked. * This argument is ignored when the callbackObj argument * is .nil. * * @return A sqlite result code. * * @notes By default, there is no trace callback installed. * * There can only be one trace callback per database connection. * Setting a new trace callback automatically clears any previously * installed callback. * * The first argument sent to the callback is the original SQL * statement text, or a comment identifying a trigger if the callback * is invoked as the result of a trigger. * * The second arugment is the userData argument to this method, if not * omitted. If userData is omitted then the third argument is .nil. */ All the SQLite functions that register a callback are implemented in ooSQLite in a similar fashion. You pass in an instantiated object where the class has a method that is invoked for the callback. They all have a default method, or you can supply your own method name if you wish. Most, if not all, of the methods have a userData argument, and that argument is passed into the callback. The other method that may be helpful is the profile() method. Here is the doc for it: /** ooSQLiteConnection::profile() * * Registers an user callback method used for profiling * * @param callbackObj [required] An instantiated class object with a method * that is invoked as each SQL statement finishes. * * This argument can also be .nil to indicate that any * installed callback is to be removed. * * @param mthName [optional] The method name that will be invoked during * a call back. By default, the method invoked will be * profileCallback(). However, the user can specify an * alternative method if desired. This argument is * ignored when the callbackObj argument is .nil. * * @param userData [optional] This can be any Rexx object the user * desires. The object will be sent as the third argument * to the profile callback method when it is invoked. * This argument is ignored when the callbackObj argument * is .nil. * * @return A sqlite result code. * * @notes By default, there is no profile callback installed. * * There can only be one profile callback per database connection. * Setting a new profile callback automatically clears any previously * installed callback. * * The first argument sent to the callback is the original statement * text. The second argument is an estimate of wall-clock time of how * long that statement took to run. The profile callback time is in * units of nanoseconds, however the current implementation is only * capable of millisecond resolution so the six least significant * digits in the time are meaningless. * * The third arugment is the userData argument to this method, if not * omitted. If userData is omitted then the third argument is .nil. * * Future versions of SQLite might provide greater resolution on the * profiler callback. The sqlite3_profile() function is considered * experimental and is subject to change in future versions of SQLite. */ Finally, there is the progressHandler() method. The doc for it: /** ooSQLiteConnection::progressHandler() * * Registers an user callback method that is invoked periodically during long * running calls to ooSQLiteConnection::exec(), and ooSQLiteStmt::step() for this * database connection. An example use for this interface is to keep a GUI * updated during a large query. * * @param callbackObj [required] An instantiated object with a method that * is invoked periodically as described above. * * This argument can also be .nil to indicate that any * installed callback is to be removed. * * @param instructions [required] the number of virtual machine instructions * that are evaluated between successive invocations of * the callback. If this argument is less than 1, it also * has the effect of removing any installed callback. * * @param mthName [optional] The method name that will be invoked during * a callback. By default, the method invoked will be * progressCallback(). However, the user can specify an * alternative method if desired. This argument is * ignored when the callbackObj argument is .nil. * * @param userData [optional] This can be any Rexx object the user * desires. The object will be sent as the first and only * argument to the progress handler callback method when * it is invoked. This argument is ignored when the * callbackObj argument is .nil. If this argument is * omitted and the callbackObj argument is not omitted, * then the .nil object is sent as the only argument to * the progress handler callback method. * * @return A sqlite result code. * * @notes By default, there is no progress handler callback installed. * * There can only be one progress callback per database connection. * Setting a new progress callback automatically clears any previously * installed callback. * * The only argument sent to the callback is the userData argument, if * supplied here, or .nil if userData is omitted. * * If the callback method returns non-zero, then the operation is * interrupted. This could be used to implement a Cancel button in a * GUI application. */ Depending on exactly what you want to do, it seems that any one of the three methods might be useful. Let me know if you find any problems with any of these methods that you might use. -- Mark Miesfeld ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Oorexx-users mailing list Oorexx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-users
