Feature req - upd cnt+optional err cde/msg

[Anonymous]

Hi all.

I'm right in the middle of attempting to unify most of the HSQLDB test suite, such as it is, into a single, script-based framework.

The reason for this is that we would like to start testing prepared and callable statements more thoroughly without writing a million test case classes, now that the HSQLDB engine supports true precompiled parametric statements internally.

Before that last few Alpha releases of HSQLDB 1.7.2, prepared statement support was done thorugh emulation in the JDBC implementation, because the database engine accepted only one entry point: execute(String, Session).  That is, the JDBC implementation was forced to merge the parameters into the statement on the client side in order to send the equivalent non-parameterized SQL character sequence to the database engine.

Anyway, SQLUnit seems to hit the spot and I can see easily translating all of our existing test script engine framework scripts to sqlunit xml files.  I can also see easily translating most of our existing specialized JUnit test cases that concern prepared and callable statements (as well as adding the fairly large number of remaining tests that I would otherwise have to write Junit test case classes for).

Here are the current shotcomings I have identified that prevent using SQLUnit as a replacement for our aging test script framework:

1.) SQLUnit does not yet have support for update count results. 

That is, many of our basic DDL/DML tests are of the form:

- do some SQL
- try to get an update count
- fail if the result is not an update count
- compare the update count with some value
- pass or fail based on the comparison

So, I would really like to see the DTD element:

<!ELEMENT result ((((outparam)*, (resultset)*)+|exception)?)>

altered so that either a result may contain something like an element:

<!ELEMENT updatecount (#PCDATA)>

The semantics I would like to see would be to only verify that the result is indeed an update count if the tags content is empty, otherwise actually compare the update count value against the tag's content.

As an XML example:

<sql>
...<stmt>
......insert into test values(1, 'abc', ...)
...</stmt>
...<result>
......<updatecount>1</updatecount>
...</result>
</sql>

2.) SQLUnit does not currently support testing results where only the row count is of concern

Often, it is enough to satisfy a test to get the correct count of rows.   In particular, SQLUnit (as far as I am aware, sorry if I'm wrong) lacks the ability to explicitly pass or fail for a zero row result, yet this is essential when testing, say, transactional functionality, such as commit, rollback and rollback to savepoint.

When I specify <resultset/> and the preceding <stmt> does generate a resultset (zero or more rows), the test passes.  Indeed, even the following passes:

<test name="Check Zero-Row Result">
...<sql>
......<stmt>insert into test(id,name) values(1,'test')</stmt>
...</sql>
...<result/>
...<sql>
......<stmt>select * from test where name = '_test'</stmt>
...</sql>
...<result>
......<resultset id="1">
.........<row id="1">
............<col id="1" type="INTEGER"></col>
............<col id="2" type="VARCHAR"></col>
.........</row>
.........<row id="1">
............<col id="1" type="INTEGER"></col>
............<col id="2" type="VARCHAR"></col>
.........</row>                   
......</resultset>
...</result>
</test>

which does not seem correct or intuitive to me.

What I would like to see is the result tag or resultset tag extended so that one of the following could be declared (no need to support more than one of these forms):

in really compact (preferred) form:

<result rowcount="n"/>

or (a little more verbose):

<result>
...<resultset rowcount="n" />
</result>

<result>
...<rowcount>n</rowcount>
</result>

or (definitely too long winded):

<result>
...<resultset>
......<rowcount>n</rowcount>
...</resultset>
</result>

3.) SQLUnit currently requires that the precise vendor code and message is known apriori when declaring an exception tag inside a result tag.

It is often sufficient or at least quite convenient to pass a test simply because an exception is thrown. 

Certainly, it is not always possible to know the precise error message that will be returned (for instance if the message refers to a system generated/named object and especially if that object was created as a result of executing the preceeding statement).

In any event, I would really like to see the <code> and <message> tags become optional children of <exception>.

Further, I think the reporting is reversed in SQLUnit regarding thrown exceptions, as when I set up a test that definitely throws an exception and declare that I am expecting a resultset, I get the following output:

No match on #-variables,
*** expected:
<result>
...<exception>
......<code>-8</code>
......<message>Integrity constraint violation SYS_FK_1 table: MAIN in statement [insert into ref values(null,2)]</message>
...</exception>
</result>
*** but got:
<result>
...<resultset id="1" />
</result>

I would think the reporing should say that I was expecting:

<result>
...<resultset id="1" />
</result>

but got...

Thanks in advance for any response,
Campbell

[Anonymous]

Sorry...one last thing:

Another very nice to have feature (indeed fairly critical to full HSQLDB testing via a unified mechanism) would be an exention to:

<!ELEMENT sql (stmt, (param)*)>

to be something like:

<!ELEMENT sql (stmt, (param)*|(batch)*)>

This would allow explicit testing of batch execution functionality, such as (for prepared and callable statements):

<sql>
...<stmt>call ...(?,?)</stmt>
...<parambatch>
......<parambatchitem id="1">
.........<param attriblist>...</param>
.........<param attriblist>...</param>
......</parambatchitem>
......<parambatchitem id="2">
.........<param attriblist>...</param>
.........<param attriblist>...</param>
......</parambatchitem>
......<parambatchitem id="3">
.........<param attriblist>...</param>
.........<param attriblist>...</param>
......</parmabatchitem>
...</parambatch>
...<result>
......<batchupdate firsterr="2">
.........<updatecount>1</updatecount>
.........<updatecount>-3</updatecount>
.........<updatecount>2</updatecount>
......</batchupdate>
...</result>
</sql>

or (for plain old Statement objects):

<sql>
...<stmtbatch>
......<stmt>call ...(...)</stmt>
......<stmt>insert...</stmt>
......<stmt>update...</stmt>
...</stmtbatch>
...<result>
......<batchupdate firsterr="2">
.........<updatecount>1</updatecount>
.........<updatecount>-3</updatecount>
.........<updatecount>2</updatecount>
......</batchupdate>
...</result>
</sql>

[Sujit Pal]

Hi Campbell,

Thanks for the detailed feature request. I am adding comments to each of your requests identified by the header.

> 1.) SQLUnit does not yet have support for update count
> results.
This should be fairly easy to put in.

> 2.) SQLUnit does not currently support testing results
> where only the row count is of concern
> When I specify <resultset/> and the preceding <stmt>
> does generate a resultset (zero or more rows), the test
> passes. Indeed, even the following passes:....
This is a bug, this is caused by comparing using the expected result as the source and the generated one as the target. I thought I had tests in there to count the number of rows and compare the two resultsets, but obviously I dont :-). Will put this fix in, thanks for catching it.

> in really compact (preferred) form:
> <result rowcount="n"/>
My preference would be this one. So if the rowcount is specified, then no comparison should be done except that the number of rows are the same?

> 3.) SQLUnit currently requires that the precise vendor
> code and message is known apriori when declaring an
> exception tag inside a result tag.
> It is often sufficient or at least quite convenient to pass a
> test simply because an exception is thrown.
I agree, we can have an empty <exception /> element to indicate that /any/ exception should be matched, if specified, then the code and message should be matched also.

> Further, I think the reporting is reversed in SQLUnit
> regarding thrown exceptions,
Yes this was caused by a fix I made in version 2.2 or thereabouts to fix another problem :-). Thanks for catching it, its already in cvs now.

> Another very nice to have feature (indeed fairly critical to
> full HSQLDB testing via a unified mechanism) would be an
> exention to:
>      <!ELEMENT sql (stmt, (param)*)>
>      to be something like:
>      <!ELEMENT sql (stmt, (param)*|(batch)*)>
Not sure what you are trying to do here. Do you want to execute a number of statements in a batch within a single sql or call tag? Perhaps in a single transaction?
Sonething similar exists in the include tag but thats callable only from setup and teardown. However, Sybase was giving some problems with batch execution so I pulled it out and replaced it with a home grown batcher (a List).

I should be able to support all your feature requests. Not sure about the last one, have to look at it some more.

-sujit

[Sujit Pal]

Updates to what I said above:
>> in really compact (preferred) form:
>> <result rowcount="n"/>
> My preference would be this one.
Sorry, it should have been
<result>
...<resultset rowcount="n" />
...other resultsets if applicable...
</result>
Since SQLUnit supports multiple resultsets returned from Sybase or MS-SQL stored procedures, so the concept of a rowcount per resultset is a meaningful one.

>> When I specify <resultset/> and the preceding <stmt>
>> does generate a resultset (zero or more rows), the test
>> passes. Indeed, even the following passes:....
This is just FYI, the above bug is fixed in CVS, and in order to specify an empty result (ie no rows), you can do:
<result />
or, more meaningfully,
<result>
...<resultset id="1" />
</result>
Both forms will work now.
I will be releasing today, so we provide a clean slate for your enhancements.

-sujit

[Anonymous]

Sujit:

Thanks a whole bunch. 

I hadn't checked back here soon enough, obviously.

I spent most of the weekend dusting off my NanoXML and JDOM props (I've been through this once before, trying to write something like Thinlet, before I know about Thinlet), trying to write a custom Parser/DOM implementation.

I managed to succeed in coming up with something somewhere between the two, weighing in at about 12K jar space (separate Parser, ParserException, Element, Attribute, Verifier and Printer classes), in order to combine with some of the techniques of SQLUnit and advance the HSQLDB test suite. 

So far, so good:  The code seems to work well and seems pretty fast (after one run warmup, parses and builds a dom from a 1MB, in-memory CharacterArrayReader in about 320 ms on my Duron 2000+ machine).

However, I'll have to look at the changes you've made to SQLUnit, as things sound pretty good.  This will certainly save a bunch of time.

In the long run, I'm hoping to provide some simple internal XML functionality for HSQLDB as well (JDK 1.1/ubiquitos browser-embedded ability to build and store in-memory xml dom from query...add true xml data type).  This requires somthing small (<16-20K) but with different features/goals than the last released version of NanoXML and probably with no need to support all of the fairly comprehesive and latest xml spec-compliant features of JDOM which weighs in far too heavy (130K jar) to make internal to the HSQLDB distribution (which is already getting large at about 530K for the full release jar, without the test case classes).

All in all, I've got to say a big thanks once again.  I'll review the changes you've made against the requirements I'm trying to meet and provide more feedback here as things progress.

Cheers,
Campbell

PS

What I meant about the batch execution thing is simply this:

The current SQLUnit DTD does not allow batches of call parameters for prepared and callable statements or batces of SQL character sequences for plain old statement objects to be built up and executed and does not allow for explicit specification of batch execution, yet that is something that I would like to have, in order to test the batch execution facility (for HSQLDB or anybody's) of the JDBC driver in question.

For example:

<sqlunit>
.. <connection>
......<driver>org hsqldb jdbcDriver</driver>
......<url>jdbc:hsqldb:mem:test</url>
......<user>sa</user>
......<password/>
.. </connection>
.. <setup/>
.. <test name="test 1">
......<sql>
........ <call>call sp1(?,?)</call>
........ <param-batch>
............ <param-set id="1">
................<param id="1" type="VARCHAR">I Will Cause An Update Count of One</param>
................<param id="2" type="INTEGER" inout="inout">1</param>
............ </param-set>
............ <param-set id="2">
................<!-- NULL in position one causes sucess-no-info -->
................<!-- execution occurs without error, but no update count is generated-->
................<param id="1" type="VARCHAR" is-null="true"/>
................<param id="2" type="INTEGER" inout="in">1</param>
............ </param-set>
............ <param-set id="2">
................<param id="1" type="VARCHAR" is-null="true"></param>
................<!-- The value -1 causes an execute-failed-->
................<param id="2" type="INTEGER" inout="in">-1</param>
............ </param-set>
............ <param-set id="1">
................<param id="1" type="VARCHAR">I Will Cause An Update Count of Zero</param>
................<param id="2" type="INTEGER" inout="in">0</param>
............ </param-set>
........ </param-batch>
........ <result>
............ <batch-result expected-length="4" first-execute-failed-index="3">
................<batch-update-count id="1">1</batch-update-count>
................<batch-success-no-info id="2"/>
................<batch-execute-failed id="3"/>
................<batch-update-count id="4">0</batch-update-count>
............ </batch-result>
........ </result>
......</sql>
....</test>
....<test name="test 2">
........<sql>
............<stmt-batch>
................<stmt>drop table test if exists</stmt>
................<stmt>create table test (id int)</stmt>
................<stmt>insert into test values(1)</stmt>
................<stmt>update test set id = 2</stmt>
................<stmt>insert into test values(1)</stmt>
................<stmt>update test set id = 2</stmt>
................<stmt>update test set id = 'A'</stmt>
................<stmt>insert into test values('A')</stmt>
............</stmt-batch>
............<result>
................ <batch-result expected-length="8" first-execute-failed-index="7">
.................. <batch-success-no-info id="1"/>
.................. <!-- Assuming the above worked, lets not bother having to..-->
.................. <!-- specify every item.. Easier/better to be allowed to.. -->
.................. <!-- specify only items of interest.. The second update....-->
.................. <!-- two rows have been inserted by then.................. -->
.................. <batch-update-count id="6">2</batch-update-count>
.................. <!-- We expected the first execute-failed to be the seventh..-->
.................. <!-- statement.. Some DBMS/Drivers will not execute a batch..-->
.................. <!-- beyond the first failed batch item, so a combination of -->
.................. <!-- first-execute-failed-index and expected-length can be.. -->
.................. <!-- can be used alone or in conjunction with child elements -->
.................. <!-- to test the expected qualities of the array or..........-->
.................. <!-- BatchUpdateException generated by the batch execution.. -->
.................. <bath-execute-failed id="8"/>
................</batch-result>
............ </result>
........</sql>
....</test>
</sqlunit>

I know its a bit muddy, really.  Needs a bit more thought and refinement.  In the most general sense, all I'm saying is that I would like to look into incorporating the ability to test batch execution explicitly via SQLUnit.  I'm not trying to dictate what needs to happen with the DTD to do this.  We should probably discuss it here some more or something.

[Sujit Pal]

The updatecount attribute and the empty exception is done and checked into cvs. I also did the rowcount and that works, but not checked in yet. I am hoping to release with all your changes by the end of this week or early next week.

For the batch update functionality, I took it to mean a set of calls that you want to execute in a transactional context. I was hoping to do something like this:
<batchtest>
..<call|sql id="n">
....<!-- content of call or sql, including param elements -->
..</call|sql>
<!-- more of call|sql -->
..<result id="n">
....<!-- content of result corresponding to call id="n" -->
..</result>
<!-- more of result -->
</batchtest>

You dont have to specify all the results, the result with id="n" will be matched up against the call|sql with id="n". If no result exists for a call|sql with id="n", no action is taken for matching.

We can add a bunch of attributes to the batchtest element in case it is run in batch and test against them, things like:
@expected-count -- expected number of result elements
@failed-at - first result failed index
@force-jdbc-batch - true|false, default true, see below for details.

The result::updatecount element can also contain the following String constants in addition to the actual update count if applicable: SUCCESS_NO_INFO | EXECUTE_FAILED. I will put this in CVS, currently there is no special handling for these.

Other features of result remain the same, including support for rowcount, updatecount, empty exceptions, etc.

This would result in (a) less work for me, since I can reuse the CallHandler, SqlHandler and ResultHandler with minimal changes :-) and (b) a more consistent user-interface since most of these are elements they have already seen before.

The @force-jdbc-batch can be set to false if the user knows that BatchUpdate is not supported by the JDBC driver.

Let me know if you think this will work for you. Its not exactly what you wanted, but should work, given the requirements.

-sujit

[Sujit Pal]

Hi Campbell,

Please ignore the stuff I said in the previous post. My experience with batching sql was only with statement objects (without parameters), so I assumed that the prepared form behaved similarly. Looking at the javadocs showed me I was wrong. Based on that, I think your design in the post before that should be fine and I am going to implement it almost as-is (I am
changing some element names). Here is the (untested) snippet from the DTD.
<!ELEMENT paramset (param)+>
  <!ATTLIST id CDATA #REQUIRED>
<!ELEMENT batchcall (stmt, (paramset)+)>
<!ELEMENT batchsql ((stmt)+)>
  <!ATTLIST id CDATA #REQUIRED>
<!ELEMENT batchresult (result)*>
  <!ATTLIST batchresult
    force-jdbc-batch (true|false) "true"
    failure-message CDATA #IMPLIED
    expected-count CDATA #IMPLIED
    failed-at CDATA #IMPLIED>
<!ELEMENT batchtest ((batchcall|batchsql), batchresult))>        
which is pretty much the same as what you specified.

Hope this works for you and sorry about the confusion :-).

-sujit

[Anonymous]

Wow, that sounds much better than what I specified and represents only a small variation and (from what I've read of your internals) represents good reuse of the existing SQLUnit functionality.

I did not get as far as I would have liked last weekend into testing how well I can convert our existing test scripts based on your last set of changes, but I'll be sure to check back here often over the next week and take the task up again as soon as possible.

Thanks again,
Campbell

[Sujit Pal]

The 2.6 version with your changes are out, but the documentation is still on my local disk, looks like I may be having some problems with shell access. Opened a bug about it, will push the documentation up once it is fixed.

Let me know if you see problems. There are some usage examples in test/mysql/batchtest.xml

-sujit

[Anonymous]

Thanks Sujit.  I'll put some time in on this over the weekend.

[Anonymous]

Just checking in to say I'm still doing work. 

Will post back here when/if I have some solid bug/defect reports and solutions or success stories.

[Sujit Pal]

Sure, no problem, thanks for the heads up. Also thanks for the pointer to DatabaseMetaData.

-sujit

[Damon Torgerson]

I have encountered a bit of a problem and I believe it may be related to the addition of updatecount.

I upgraded to 3.1 and immediately my tests that compare clob output failed. I was coomparing the output from a procedure with that of a file. Here's a sample call (I hope the formating isn't too bad):

<test name="stm.locSetAddress - 2">
        <call>
            <stmt>{call stm_app.locSetAddress(?,?) }</stmt>
            <param id="1" type="VARCHAR"><![CDATA[<?xml version="1.0"?><address><partyId>5</partyId><addressType>HomeAddress</addressType><effectiveDate xmlns:q1="http://www.w3.org/2001/XMLSchema" d2p1:type="q1:string" xmlns:d2p1="http://www.w3.org/2001/XMLSchema-instance">2004-01-13T12:41:41.202</effectiveDate><location><modified>2003-12-03T13:52:13.803</modified><code>US</code><name>UNITED STATES</name><locationType>Country</locationType></location><location><name>12345 Main St.</name><locationType>Street</locationType></location><location><name>Seattle</name><locationType>City</locationType></location><location><name>WASHINGTON</name><locationType>State</locationType></location><location><name>98112</name><locationType>PostalCode</locationType></location></address>]]></param>
            <param id="2" type="INTEGER">1</param>
        </call>
        <result>
            <resultset id="1">
                <row id="1">
                    <col id="1" type="LONGVARCHAR">file:test\location\xmloutput\locSetAddress2CLOB.xml</col>
                </row>
            </resultset>
        </result>
    </test>

The result of the test would verify whether or not my CLOB output was the same as the xml contained within the file.

Now, it doesn't compare the CLOB output with the file. It only checks the updatecount.

I tried rolling back to version 2.8 but it appears that the dtd was changed to include the updatecount changes.

Am I barking up the wrong tree?

Damon

I

[Sujit Pal]

This appears to be a bug that I may have introduced when updatecount attribute was added (or not). Thanks for the detailed bug report. I will look at the problem on my way home and try to fix it. I should have an answer for you by tomorrow morning.

-sujit

[Sujit Pal]

I looked at the code, the reason it compares updatecount from the code in CallHandler is because CallableStatement.execute() returns a false. This will happen when the first result returned is an updatecount.

You may want to take a look at the TUI tool. It generates the result SQLUnit would expect for you, that might give you a start in figuring out what the problem is.

I also checked the diffs for the CallHandler code in version 2.8 and version 3.1, the only change is the removal of the deprecated process() method, so the version change is probably not related to this problem.

If you could see what the TUI tool generates, or if you could take a look at the stored procedure itself, that would be helpful. I will build up a test case myself with the information you sent and try to see why it fails.

-sujit

[Damon Torgerson]

Thanks Sujit,

I will look into the TUI tool. I did not change anything other than the version of SQL Unit...the stored procedure works the same in my application...

I will dig a little deeper...it's time I started contributing rather than just expecting everyone else to.

Thanks,
Damon

[Sujit Pal]

Hi Damon,

Sorry for going pretty much off the air for the last week, but I was really busy at work. Anyway, I tried setting up a PostgreSQL test like this:
create or replace function PassThru(varchar) returns varchar as '
  declare
    i_param alias for $1;
  begin
    return i_param;
  end;
' language 'plpgsql';
and a test case like this:
  <test name="Passthrough test">
    <sql>
      <stmt>select PassThru(?)</stmt>
      <param id="1" type="VARCHAR"><![CDATA[<?xml version="1.0"?><address><partyId>5</partyId><addressType>HomeAddress</addressType><effectiveDate xmlns:q1="http://www.w3.org/2001/XMLSchema"; d2p1:type="q1:string" xmlns:d2p1="http://www.w3.org/2001/XMLSchema-instance">2004-01-13T12:41:41.202</effectiveDate><location><modified>2003-12-03T13:52:13.803</modified><code>US</code><name>UNITED STATES</name><locationType>Country</locationType></location><location><name>12345 Main St.</name><locationType>Street</locationType></location><location><name>Seattle</name><locationType>City</locationType></location><location><name>WASHINGTON</name><locationType>State</locationType></location><location><name>98112</name><locationType>PostalCode</locationType></location></address>]]></param>
    </sql>
    <result>
      <resultset id="1">
        <row id="1">
          <col id="1" type="VARCHAR"><![CDATA[<?xml version="1.0"?><address><partyId>5</partyId><addressType>HomeAddress</addressType><effectiveDate xmlns:q1="http://www.w3.org/2001/XMLSchema"; d2p1:type="q1:string" xmlns:d2p1="http://www.w3.org/2001/XMLSchema-instance">2004-01-13T12:41:41.202</effectiveDate><location><modified>2003-12-03T13:52:13.803</modified><code>US</code><name>UNITED STATES</name><locationType>Country</locationType></location><location><name>12345 Main St.</name><locationType>Street</locationType></location><location><name>Seattle</name><locationType>City</locationType></location><location><name>WASHINGTON</name><locationType>State</locationType></location><location><name>98112</name><locationType>PostalCode</locationType></location></address>]]></col>
        </row>
      </resultset>
    </result>
  </test>
--
and it works with the code I have (3.1+). However, when I point to the result using file: it converts it to md5 and the run fails. I remember that I had some good reasons at one time to do md5, have to take a more detailed look at the code again.

I have also instrumented SQLUnit with log4j debugging statements, so turning debug=true will dump a debug trace (very verbose) on the console. You may want to run your test case with that and post the debug trace on the forum, so I can get some more info to debug your problem.

I would like to hold off making a release till we are able to get a better handle on your problem, unless someone needs a release urgently, let me know.

Thanks
Sujit

[Sujit Pal]

I have put in some fixes relating to comparing results specified in files using the file: prefix that you were using. SQLUnit assumes that content stored in files are going to be large, so it does not attempt to do a string compare. It digests the supplied file into an md5 string. The problem was that when the comparison was being done, the source was not getting digested to an md5 before the comparison. That is now fixed. Take a look at the PassThru.sql and its associated test in test.xml, both in the test/postgresql directory.

Let me know if you have problems. Were you able to resolve the problem you mentioned earlier?

Thanks
Sujit

[Damon Torgerson]

Sujit,

I've been off line for the past couple of weeks. I will look at this and get back to you.

Thanks,
Damon

[Damon Torgerson]

The problem still seems to exist. If I use

<result>
....
<col type="LONGVARCHAR">file:/myfile.xml</col>
....

the result is digested into an md5 and compared to the original...and my test fails.

If I use

<result>
....
<col type="VARCHAR">file:/myfile.xml</col>
....

My test fails and a text file containing the xml is output to a temp directory. The resulting xml file is identical to the test xml file.

I hope this isn't too ambiguious.

Here's the debug output from using type="VARCHAR"

*******************************
*******************************
procs.location.test:
  [sqlunit] 0    [main] DEBUG sqlunit  - >> testWrapper()
  [sqlunit] 0    [main] DEBUG sqlunit  - >> processDoc()
  [sqlunit] 15   [main] DEBUG sqlunit  - >> setTestFile(C:\stm\STMCode\Database\src\test\location\location_tests.xml)
  [sqlunit] *** Running SQLUnit file: C:\stm\STMCode\Database\src\test\location\location_tests.xml
  [sqlunit] 156  [main] DEBUG sqlunit  - >> getDefaultConnection()
  [sqlunit] Getting connection(DEFAULT)
  [sqlunit] 171  [main] DEBUG sqlunit  - >> getInstance(connection)
  [sqlunit] 171  [main] DEBUG sqlunit  - >> process()
  [sqlunit] 343  [main] DEBUG sqlunit  - >> setDefaultConnection()
  [sqlunit] Setting up test...
  [sqlunit] 343  [main] DEBUG sqlunit  - >> getInstance(setup)
  [sqlunit] 359  [main] DEBUG sqlunit  - >> process(elSetup)
  [sqlunit] 359  [main] DEBUG sqlunit  - >> getInstance(include)
  [sqlunit] 359  [main] DEBUG sqlunit  - >> process(elInclude)
  [sqlunit] 359  [main] DEBUG sqlunit  - >> getDefaultConnection()
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> addRunCount()
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> getInstance(test)
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> process(elTest)
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> setValue(__JavaObjectSupport__,off)
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> setValue(__FailureMessage__,null)
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> getInstance(call)
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> process()
  [sqlunit] 4000 [main] DEBUG sqlunit  - >> getDefaultConnection()
  [sqlunit] 4078 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(INTEGER)
  [sqlunit] 4078 [main] DEBUG sqlunit  - >> createFieldMap()
  [sqlunit] 4078 [main] DEBUG sqlunit  - >> convertToObject(1,INTEGER)
  [sqlunit] 4078 [main] DEBUG sqlunit  - >> isVariableName(1)
  [sqlunit] 4078 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(INTEGER)
  [sqlunit] 4093 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4093 [main] DEBUG sqlunit  - >> convertToObject(HomeAddress,VARCHAR)
  [sqlunit] 4093 [main] DEBUG sqlunit  - >> isVariableName(HomeAddress)
  [sqlunit] 4093 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4093 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(TIMESTAMP)
  [sqlunit] 4093 [main] DEBUG sqlunit  - >> convertToObject(2004-01-12 14:14:54.090,TIMESTAMP)
  [sqlunit] 4109 [main] DEBUG sqlunit  - >> isVariableName(2004-01-12 14:14:54.090)
  [sqlunit] 4109 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(TIMESTAMP)
  [sqlunit] 4109 [main] DEBUG sqlunit  - [DatabaseResult]
  [sqlunit] 4109 [main] DEBUG sqlunit  - >> setEmpty(true)
  [sqlunit] 4234 [main] DEBUG sqlunit  - >> setEmpty(false)
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> setNumCols(1,1)
  [sqlunit] 4250 [main] DEBUG sqlunit  - [DatabaseResultKey(1,1,1)]
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> setResultSetId(1)
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> setRowId(1)
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> setColId(1)
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> renderLOB(bytes,2)
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> getMD5CheckSum(bytes[],true)
  [sqlunit] 4250 [main] DEBUG sqlunit  - >> writeLOB(bytes[])
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> getValue(__currDRK__)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> setValue(__file:null,C:\Documents and Settings\damo1727\Local Settings\Temp\sqlunit-lob-42546.dat)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> setValue(key,md5:56361a8d6cd205d8f66f4085e941c686,-1)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> getXmlTypeFromSqlType(-1)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> setValue(key,md5:56361a8d6cd205d8f66f4085e941c686,LONGVARCHAR)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> setNumRows(1,1)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> setNumResults(1)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> getInstance(result)
  [sqlunit] 4265 [main] DEBUG sqlunit  - >> process(elResult)
  [sqlunit] 4265 [main] DEBUG sqlunit  - [DatabaseResult]
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> renderLOB(bytes,0)
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> getMD5CheckSum(istream)
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> getMD5CheckSum(bytes[],false)
  [sqlunit] 4281 [main] DEBUG sqlunit  - [DatabaseResultKey(1,1,1)]
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> setResultSetId(1)
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> setRowId(1)
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> setColId(1)
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> setValue(key,md5:56361a8d6cd205d8f66f4085e941c686,VARCHAR)
  [sqlunit] 4281 [main] DEBUG sqlunit  - >> setNumCols(1,1)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> setNumRows(1,1)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> setNumResults(1)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> setValue(__JavaObjectSupport__,null)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> update(target,source)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> isException()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> isRowCountOverride()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getValues()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getValues()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getKeys()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getValue(key)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getValueType(key)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> isVariableName(md5:56361a8d6cd205d8f66f4085e941c686)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> customEquals(expR,gotR)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> customEquals(expR,gotR,patObj)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> isEmpty()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getOutParamIds()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getUpdateCount()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getUpdateCount()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getNumResults()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowCountOverride(1)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getKeys()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowCountOverride(1)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> isRowCountOverride()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getValue(key)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4297 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getValue(key)
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getValueType(key)
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getValueType(key)
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> toString()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> toString()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> toElement()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getOutParamIds()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getUpdateCount()
  [sqlunit] 4312 [main] DEBUG sqlunit  - >> getNumResults()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getNumRows(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getNumCols(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - [DatabaseResultKey(1,1,1)]
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> setResultSetId(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> setRowId(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> setColId(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getValue(key)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getValueType(key)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getNumCols(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getNumRows(1)
  [sqlunit] 4375 [main] DEBUG sqlunit  - >> getNumResults()
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> toString()
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> toElement()
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> getOutParamIds()
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> getUpdateCount()
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> getNumResults()
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> getNumRows(1)
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> getNumCols(1)
  [sqlunit] 4390 [main] DEBUG sqlunit  - [DatabaseResultKey(1,1,1)]
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> setResultSetId(1)
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> setRowId(1)
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> setColId(1)
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> getValue(key)
  [sqlunit] 4390 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getValueType(key)
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> compareTo(obj)
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getResultSetId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getRowId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getColId()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getNumCols(1)
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getNumRows(1)
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getNumResults()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> failureMessage()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getValue(__FailureMessage__)
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> addFailureCount()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> setLastException(e)
  [sqlunit] Running test[1]: locGetAddress (406ms)
  [sqlunit] No match on type at [rset,row,col]=([1,1,1]
  [sqlunit] *** expected:
  [sqlunit] <result>
  [sqlunit]   <resultset id="1">
  [sqlunit]     <row id="1">
  [sqlunit]       <col id="1" type="VARCHAR">md5:56361a8d6cd205d8f66f4085e941c686</col>
  [sqlunit]     </row>
  [sqlunit]   </resultset>
  [sqlunit] </result>
  [sqlunit] *** but got:
  [sqlunit] <result>
  [sqlunit]   <resultset id="1">
  [sqlunit]     <row id="1">
  [sqlunit]       <col id="1" type="LONGVARCHAR">md5:56361a8d6cd205d8f66f4085e941c686</col>
  [sqlunit]     </row>
  [sqlunit]   </resultset>
  [sqlunit] </result>

  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getSymbols()
  [sqlunit] 4406 [main] DEBUG sqlunit  - >> getValue(__file:null)
  [sqlunit] For test[3], result null, created temp file: C:\Documents and Settings\damo1727\Local Settings\Temp\sqlunit-lob-42546.dat
  [sqlunit] Tearing down test...
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> getInstance(teardown)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> process(elTeardown)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> getInstance(sql)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> process(elSql)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> getDefaultConnection()
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> convertToObject(BILLY,VARCHAR)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> isVariableName(BILLY)
  [sqlunit] 4422 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4422 [main] DEBUG sqlunit  - [DatabaseResult]
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> setNumResults(0)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> setEmpty(true)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> setUpdateCount(0)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> getInstance(sql)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> process(elSql)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> getDefaultConnection()
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> convertToObject(BOUROUGH,VARCHAR)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> isVariableName(BOUROUGH)
  [sqlunit] 4453 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4453 [main] DEBUG sqlunit  - [DatabaseResult]
  [sqlunit] 4468 [main] DEBUG sqlunit  - >> setNumResults(0)
  [sqlunit] 4468 [main] DEBUG sqlunit  - >> setEmpty(true)
  [sqlunit] 4468 [main] DEBUG sqlunit  - >> setUpdateCount(0)
  [sqlunit] 4468 [main] DEBUG sqlunit  - >> getInstance(sql)
  [sqlunit] 4468 [main] DEBUG sqlunit  - >> process(elSql)
  [sqlunit] 4468 [main] DEBUG sqlunit  - >> getDefaultConnection()
  [sqlunit] 4484 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4484 [main] DEBUG sqlunit  - >> convertToObject(BAYOU,VARCHAR)
  [sqlunit] 4484 [main] DEBUG sqlunit  - >> isVariableName(BAYOU)
  [sqlunit] 4484 [main] DEBUG sqlunit  - >> getSqlTypeFromXmlType(VARCHAR)
  [sqlunit] 4484 [main] DEBUG sqlunit  - [DatabaseResult]
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> setNumResults(0)
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> setEmpty(true)
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> setUpdateCount(0)
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> releaseConnections()
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> wasSuccessful()
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> errorCount()
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> failureCount()
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> toString()
  [sqlunit] 4500 [main] DEBUG sqlunit  - >> getLastException()
  [sqlunit] SQLUnit Tests Failed: In file: C:\stm\STMCode\Database\src\test\location\location_tests.xml, tests: 1, failures: 1, errors = 0
  [sqlunit] net.sourceforge.sqlunit.SQLUnitException: SQLUnit Tests Failed: In file: C:\stm\STMCode\Database\src\test\location\location_tests.xml, tes
ts: 1, failures: 1, errors = 0
  [sqlunit]     at net.sourceforge.sqlunit.SQLUnit.testWrapper(SQLUnit.java:143)
  [sqlunit]     at net.sourceforge.sqlunit.SQLUnit.runTest(SQLUnit.java:128)
  [sqlunit]     at net.sourceforge.antsqlunittask.SqlunitTask.execute(SqlunitTask.java:98)
  [sqlunit]     at org.apache.tools.ant.Task.perform(Task.java:341)
  [sqlunit]     at org.apache.tools.ant.Target.execute(Target.java:309)
  [sqlunit]     at org.apache.tools.ant.Target.performTasks(Target.java:336)
  [sqlunit]     at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
  [sqlunit]     at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:397)
  [sqlunit]     at org.apache.tools.ant.Task.perform(Task.java:341)
  [sqlunit]     at org.apache.tools.ant.Target.execute(Target.java:309)
  [sqlunit]     at org.apache.tools.ant.Target.performTasks(Target.java:336)
  [sqlunit]     at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
  [sqlunit]     at org.apache.tools.ant.Project.executeTargets(Project.java:1255)
  [sqlunit]     at org.apache.tools.ant.Main.runBuild(Main.java:609)
  [sqlunit]     at org.apache.tools.ant.Main.start(Main.java:196)
  [sqlunit]     at org.apache.tools.ant.Main.main(Main.java:235)
  [sqlunit] Caused by: net.sourceforge.sqlunit.SQLUnitException: No match on type at [rset,row,col]=([1,1,1]
  [sqlunit] *** expected:
  [sqlunit] <result>
  [sqlunit]   <resultset id="1">
  [sqlunit]     <row id="1">
  [sqlunit]       <col id="1" type="VARCHAR">md5:56361a8d6cd205d8f66f4085e941c686</col>
  [sqlunit]     </row>
  [sqlunit]   </resultset>
  [sqlunit] </result>
  [sqlunit] *** but got:
  [sqlunit] <result>
  [sqlunit]   <resultset id="1">
  [sqlunit]     <row id="1">
  [sqlunit]       <col id="1" type="LONGVARCHAR">md5:56361a8d6cd205d8f66f4085e941c686</col>
  [sqlunit]     </row>
  [sqlunit]   </resultset>
  [sqlunit] </result>

  [sqlunit]     at net.sourceforge.sqlunit.DatabaseResult.customEquals(DatabaseResult.java:421)
  [sqlunit]     at net.sourceforge.sqlunit.DatabaseResult.customEquals(DatabaseResult.java:338)
  [sqlunit]     at net.sourceforge.sqlunit.TestHandler.process(TestHandler.java:90)
  [sqlunit]     at net.sourceforge.sqlunit.SQLUnit.processDoc(SQLUnit.java:218)
  [sqlunit]     at net.sourceforge.sqlunit.SQLUnit.testWrapper(SQLUnit.java:140)
  [sqlunit]     ... 15 more
  [sqlunit] SQLUnit Tests Failed: In file: C:\stm\STMCode\Database\src\test\location\location_tests.xml, tests: 1, failures: 1, errors = 0

BUILD FAILED

file:C:/stm/STMCode/Database/src/test/build.xml:45: SQLUnit Tests Failed: In file: C:\stm\STMCode\Database\src\test\location\location_tests.xml, tests

1, failures: 1, errors = 0

*****************************
*****************************

[Sujit Pal]

Hi Damon,

Thanks for the debug trace. Not sure what the problem is yet, but I will look at it this evening and get back to you tomorrow morning.

I did notice something similar to what you saw when testing the functionality. Since files are digested before the compare, they have to be /exactly/ indentical. I tried diffing the two, but could not find any differences, so I copied the generated file to be the test file, and everything went fine after that. May be something to do with md5, not too sure of that though.

-sujit

[Damon Torgerson]

Something I noticed just after I posted...

The resulting md5 is correct when you select VARCHAR as the datatype but the resulting type is LONGVARCHAR. Here's the snippet of output...

[sqlunit] *** expected:
[sqlunit] <result>
[sqlunit] <resultset id="1">
[sqlunit] <row id="1">
[sqlunit] <col id="1" type="VARCHAR">md5:56361a8d6cd205d8f66f4085e941c686</col>
[sqlunit] </row>
[sqlunit] </resultset>
[sqlunit] </result>
[sqlunit] *** but got:
[sqlunit] <result>
[sqlunit] <resultset id="1">
[sqlunit] <row id="1">
[sqlunit] <col id="1" type="LONGVARCHAR">md5:56361a8d6cd205d8f66f4085e941c686</col>
[sqlunit] </row>
[sqlunit] </resultset>
[sqlunit] </result>

[Sujit Pal]

Yes, I noticed that later in the evening, and the failure was actually valid in this case, since the data type was mismatched.

In any case, the problem was that for certain data types such as BLOB, CLOB, LONGVARCHAR and LONGVARBINARY, SQLUnit digests the value returned from the stored procedure to an MD5. So in this case, SQLUnit was actually comparing the MD5 of the contents of your file with the MD5 of the MD5 digest of the content returned from the database.

I have fixed that, will push it into CVS and make a release this evening.

I am curious about one thing though. The log you sent me, was it with the same log4j.properties file that was included with the distribution or did you change the pattern? I ask because when I run the sqlunit-flat target from my local installation I get file names and line numbers as well. The latter is a great help in tracking down problems, the only help I got from your debug trace was the stack trace.

-sujit

[Damon Torgerson]

I used a custom log4j properties file. I didn't realize there was one packaged with sqlunit. I'm pretty new to log4j.

Thanks for fixing this bug and sorry for making extra work for you.

Damon

[Sujit Pal]

Hi Damon,

No problem with that one, was just curious if log4j behaved differently with and without the source. I am glad we could finally fix the bug, thanks a lot for finding and reporting it, and I appreciate the detective work with VARCHAR and LONGVARCHAR as well. That actually helped nail it down somewhat.

-sujit