On Mon, Sep 17, 2012 at 7:07 AM, Staffan Tylen <staffan.ty...@gmail.com>
wrote:
> I've slowly started the task to convert code from using RexxSQL to
ooSQLite
> and have the following first questions (I'm sure there will be more):
>
> - the 'new' methods in the supplied ooSQLite classes are all documented as
> class methods. I find this a bit strange, as any parameters such as a file
> name will be universal for the class, not for an individual instance of
the
> class. What's the thinking behind this?
The 'new' method of a class returns a new object of that class. A name
such as the file name is universal to the object not the class.
Take the ooSQLiteConnection class which represents a connection to a single
database. The file name here is the database file name. So to use a
connection to a specific database you create an object for that database:
dbConnFoods = .ooSQLiteConnection~new('ooFoods.rdbx',
.ooSQLite~OPEN_READWRITE)
To open up a connection to another database:
dbConnPhone = .ooSQLiteConnection~new('phonebook.db',
.ooSQLite~OPEN_READWRITE)
You now have 2 ooSQLiteConnection objects, each one a connection to a
different database. 'new' is a class method, not an instance method.
The same basic reasoning applies to all the other classes supplied by
ooSQLite.
> - I presume that the 'exec' method of the ooSQLiteConnection class
> corresponds to the sqlite_exec() API, but unfortunately the documentation
> doesn't seem to match the API, as it only shows a cryptic optional
parameter
> 'type'. So how do I invoke the sqlite_exec() API?
Unfortunately, the documentation is lagging here. As a hint in general,
whenever you see a method like this:
>>--exec(--+--------+--)--------------------><
+--type--+
it is just a placeholder for the documentation. In the current
documentation, there is a place holder for all the classes and methods of
those classes. But, much, most, of the method documentation has not been
filled in.
For many of the methods, the documentation would pretty much be the same as
the SQLite documentation for the similar function.
However, exec() is a little bit of a special case, because of the callback
feature of SQLite. The SQLite doc shows this for exec()
int sqlite3_exec(
sqlite3*, /* An open database */
const char *sql, /* SQL to be evaluated */
int (*callback)(void*,int,char**,char**), /* Callback function */
void *, /* 1st argument to callback */
char **errmsg /* Error msg written here */
);
In ooSqlite, exec() is a method of ooSQLiteConnection, so the "open
database" is known to the object, you don't pass in the open database. In
ooSQLIte the method will look like:
>>--exec(--sql-+---------+-+----------+-+---------+-+-----------+-+---------+--)---><
+-,-useCB-+ +-,-format-+ +-,-cbObj-+ +-,-mthName-+
+-,-uData-+
The first argument: sql the SQL string to be evaluated.
The second argument: useCB The second argument is true or false to
indicate whether you want the callback feature to be used or not. If false,
no callback is used. This is the same as not specifying a callback in
SQLite. If true a callback is used.
The arguments following the second argument determine how the callback is
done. If argument 2 is false, all the following arguments are ignored.
If argument 2 is true, you can either have ooSQLite use an internal
callback, or you can specify your own callback in your Rexx code to be
used. If you omit the fourth argument, the internal callback is used and
exec() will return a result set. This is the simplest usage and several
example programs show this usage. For instance, in execTestA.rex, you will
see this:
dbName = 'ooFoods.rdbx'
dbConn = .ooSQLiteConnection~new(dbName, .ooSQLite~OPEN_READWRITE)
sql = 'SELECT * FROM foods ORDER BY name;'
resultSet = dbConn~exec(sql, .true)
The third argument: format specifies the format of the returned result.
When omitted it the default format is used. You can change the default
using the third argument to exec() for that invocation of exec(). You
change it using one of the result set constants, which are explained in
3.1.2. recordFormat (Attribute) in the doc.
The fourth argument: cbObj Rather than use the internal callback, you can
have a callback in your own object invoked. If the fourth argument is
omitted, the internal callback is used. If you pass in a object as the
fourth argument, a method is invoked in that object for each result row
coming out of the evaluated SQL statements. By default, the method invoked
is: execCallBack()
The fifth argument: mthName This argument can specify the method name to
be invoked in your callback object. When omitted, the method invoked is:
execCallBack(). When used, it is the name of the method you want invoked
in your callback object.
The sixth argument: uData (user data) This can be any Rexx object you
want. If specified, this object is passed to your callback object.
The fifth and sixth arguments are ignored if the fourth argument is omitted.
I'll try to document exec() and put up a new oosqlite.pdf on SourceForge.
This will hopefully be clearer.
This will push me to try and get the doc squared away.
--
Mark Miesfeld
------------------------------------------------------------------------------
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/
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
