RE: SQL Extension

[sc...@us.ibm.com]

I'm waiting for John Gentilin to answer.  Since I just noticed that I
didn't read and haven't answered a note he sent me a couple of weeks ago,
maybe he's made at me and won't answer.  :-(

Anyway, I'm under the impression that a few people are using this extension
successfully.  It's a really cool extension, and I would like to see more
work on it.  It's probably not as robust as it ought to be.  I think we
only have a really basic test of it in our test suite.

-scott

Re: SQL Extension

[John Gentilin <ge...@eyecatching.com>]

Oops, I must of missed something. Is there a problem I am not aware of ??
The only item that fell through the cracks was the question of fixing the
FilterExprWalker
where a null nodeSet would not perform the default behavior which would cause
NPE's
when a null was returned in the case of an SQL error (exception processing).
There was
some talk on the behavior of a null node set, but no one ever said yes or no.

Please resend the previous issue and I will look at i right away.

Regards
John G


scott_boag@us.ibm.com wrote:

> I'm waiting for John Gentilin to answer.  Since I just noticed that I
> didn't read and haven't answered a note he sent me a couple of weeks ago,
> maybe he's made at me and won't answer.  :-(
>
> Anyway, I'm under the impression that a few people are using this extension
> successfully.  It's a really cool extension, and I would like to see more
> work on it.  It's probably not as robust as it ought to be.  I think we
> only have a really basic test of it in our test suite.
>
> -scott

Re: SQL Extension

[Phil Friedman <pf...@terralink.com>]

I've used the SQL extensions to import and export data from FoxPro, MS
SQL Server (both using NetDirect JDBC drivers) and Sybase SQL Anywhere.
Other than a few quirks (you MUST have a result from your SQL, comes to
mind) I do inserts, updates and selects on many different datatypes. I
don't use any java other than a shell to start to call xslt.Process.

However, I realized early on that what you get from sql:query is not a
"real" XML node or tree-fragment or what ever it's supposed to be. I'd
suggest processing the results into a "real" node before I tried to hand
it off to Java, something like this:

    <xsl:variable name="SQL">
      select ...
    </xsl:variable>
    <xsl:variable name="Qy" select="sql:query($DbCon, $SQL)"/>
    <xsl:apply-templates select="$Qy/ext-error"/> <!-- log errors -->
    <!-- package the results -->
    <xsl:for-each select="$Qy/row-set/row">
      <xsl:for-each select="col">
        <xsl:attribute name="{@column-name}"><xsl:value-of select="text()"/></xsl:attribute>
      </xsl:for-each> <!-- col -->
    </xsl:for-each> <!-- row -->

where you save each row or all rows into a variable for you java code to
access. Hope this helps.


Regards,  Philip Friedman -- Terralink Software Systems -- 207-772-6500 x101

On Tue, 26 Mar 2002 15:06:33 -0500, scott_boag@us.ibm.com may have written:

|
|I'm waiting for John Gentilin to answer.  Since I just noticed that I
|didn't read and haven't answered a note he sent me a couple of weeks ago,
|maybe he's made at me and won't answer.  :-(
|
|Anyway, I'm under the impression that a few people are using this extension
|successfully.  It's a really cool extension, and I would like to see more
|work on it.  It's probably not as robust as it ought to be.  I think we
|only have a really basic test of it in our test suite.
|
|-scott
|
|