I am just playing with CursorAdapter to connect via ODBC to a Sybase SQL Anywhere backend and found
a few things I thought You should also know.

Using the builder, it takes care of creating the connection to the server via sqlStringConnect(),
witch is kinda nice. However he forgets to do the cleanup for that. There's no sqlDisconnect()
anywhere. So, if You have a developer license like me, you can call Your procedure that creates
the CA, does the job and releases the CA about ten times. On the next call You receive a very
nice "maximum number of connections exceeded" - error.

So, if the builder creates code that does not care a damn if I already have a connection that I
could possibly provide (the connection is established in the init), why does it not a least do
the cleanup for that?

So either You check "Use connection settings in builder only" and take care of that Yourself or create
something like

...
case This.DataSourceType = "ODBC"
    if vartype(This.DataSource) ="N"
        if used(This.Alias)
            use in (This.Alias)
        endif	
        =sqlDisconnect(This.DataSource)
    endif
endcase

in the destroy, if You want to leave everything else untouched (the cursor gets closed anyway when the object is destroyed).

You also might come up with the idea to use a shared connection witch the builder does not do for You.

Another pit You might fall into (at least I did) comes up, when You start to subclass your CursorAdapters because they in most cased connect to the same database. Let's assume You let the Base class do the connection and errorhandling and let the subclasses do the taskspecific stuff. If You work on the subclass, use the builder and forget to check the "Use connection settings in builder only" checkbox, it will create the sqlStringConnect() stuff in the init of the subclass. Despite the fact that this is not what You want, there is a tiny little doDefault() in the init. This causes to call the init of the parent-class witch creates the connection and stores the (vital) handle, followed by the rest of the init of the child-class witch again creates a connection (without releasing the other one first) plus overwriting the old handle information in the DataSource property. That makes two dangling connections per call, or at least one If You do the cleanup.


Nothing severe, just something I thought You might like to know when You start using CursorAdapters.