i'm getting the following error message in one of my many tests:
[sqlunitdef] Running test[6]: compare-0005-01-pos-invoice (0ms)
[sqlunitdef] The data " " is not legal for a JDOM character content: 0x0 is not a legal XML character.
[sqlunitdef] For test[6], ${result[1,1,5]}, created temp file C:\Documents and Settings\xyz\Local Settings\Temp\sqlunit-lob-46942.dat
I get this error then i test against one database, but not, if i test against an another database (which are the same in the structure, but one in the dev, the other in the preprod environment), so IMHO this is not a problem of the testfile itself.
Anybody a hint?
Bye
Che***
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could it be an issue with the data? There may be some data in preprod which is stopping SQLUnit from building the XML output. You will probably see this if you run the stored procedure manually against the preprod database. Although the JDOM error message is a little strange, I was not aware that spaces is an invalid character value. If you can post your XML snippet that would be very helpful too.
-sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have analysed the C-code, which does the insert into the db.
Found some initialisation of unsigned char variables with a binary "0" (char 0x0), which are inserted into CHAR and VARCHAR fields. Looking with Quest SQLNavigator into the db, the fields looks empty, but in reality they hold a binary "0". So, JDom fails to work with this data.
Thanks for your reply!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to know that it was a data issue. And looks like SQLUnit did the right thing (sort of) by flagging the error, although we could probably make the 0x0 binary character "legal" to JDOM by changing the encoding (not sure about that though). If you are able to find any workaround (so SQLUnit reports a mismatch rather than throw a JDOM exception) for this test case, would appreciate you letting us know.
Thanks
Sujit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Folks,
i'm getting the following error message in one of my many tests:
[sqlunitdef] Running test[6]: compare-0005-01-pos-invoice (0ms)
[sqlunitdef] The data " " is not legal for a JDOM character content: 0x0 is not a legal XML character.
[sqlunitdef] For test[6], ${result[1,1,5]}, created temp file C:\Documents and Settings\xyz\Local Settings\Temp\sqlunit-lob-46942.dat
I get this error then i test against one database, but not, if i test against an another database (which are the same in the structure, but one in the dev, the other in the preprod environment), so IMHO this is not a problem of the testfile itself.
Anybody a hint?
Bye
Che***
Hi Che---,
Could it be an issue with the data? There may be some data in preprod which is stopping SQLUnit from building the XML output. You will probably see this if you run the stored procedure manually against the preprod database. Although the JDOM error message is a little strange, I was not aware that spaces is an invalid character value. If you can post your XML snippet that would be very helpful too.
-sujit
Hi,
yes, it was really a data issue!
I have analysed the C-code, which does the insert into the db.
Found some initialisation of unsigned char variables with a binary "0" (char 0x0), which are inserted into CHAR and VARCHAR fields. Looking with Quest SQLNavigator into the db, the fields looks empty, but in reality they hold a binary "0". So, JDom fails to work with this data.
Thanks for your reply!
Hi Che---,
Good to know that it was a data issue. And looks like SQLUnit did the right thing (sort of) by flagging the error, although we could probably make the 0x0 binary character "legal" to JDOM by changing the encoding (not sure about that though). If you are able to find any workaround (so SQLUnit reports a mismatch rather than throw a JDOM exception) for this test case, would appreciate you letting us know.
Thanks
Sujit