Hello, We're trying to develop a generic SQL processor. We use the <sql:param ...> syntax to generate the dynamic query. The query is delimited by quotes and could not be processed by the database engine. What the better way to access XPL input data field in a SQL processor ? Thanks and regards David. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
David,
Your question is a little vague: can you provide an example? What do you mean by "The query is delimited by quotes and could not be processed by the database engine"? What database are you using? The <sql:param> element is used to set parameters on a JDBC PreparedStatement, and this is database-independent. -Erik [hidden email] wrote: > Hello, > > We're trying to develop a generic SQL processor. > > We use the <sql:param ...> syntax to generate the dynamic query. > > The query is delimited by quotes and could not be processed by the database engine. > > What the better way to access XPL input data field in a SQL processor ? > > Thanks and regards > > David. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
In reply to this post by david.sportes
Hello,
I have run further tests which show that it is not true that Base64 alone would be responsible. The codes I sent yesterday do two things: a. it does usual processing (encoding) then I decode to see if the result is equal to the source string b. I added some additional code to do simply Base64 encoding and decoding. After doing a. and b. I test for string equality. In my further tests I found that in some occasions test a.) already produces an incorrect result (source and destination strings do not match) and also other occasions when test a. was OK but test b.) resulted in string differences. I do not know if it is significant but there was no occasion yet when both resulted in error. regards, Balazs p.s. What did you exactly mean by "end of string" ? (The string is the XML instance so my special characters are naturally inside the string.) -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
[hidden email] wrote:
> Hello, > > I have run further tests which show that it is not true that Base64 alone would be responsible. > The codes I sent yesterday do two things: > a. it does usual processing (encoding) then I decode to see if the result is equal to the source string > b. I added some additional code to do simply Base64 encoding and decoding. > After doing a. and b. I test for string equality. > > In my further tests I found that in some occasions test a.) already produces an incorrect result (source and destination strings do not match) and also other occasions when test a. was OK but test b.) resulted in string differences. I do not know if it is significant but there was no occasion yet when both resulted in error. > > > > regards, > Balazs > > p.s. What did you exactly mean by "end of string" ? (The string is the XML instance so my special characters are naturally inside the string.) end of the Base64 stream, and this would only impact the last characters of your initial instance string. But since the corrupted characters are in the middle, this is likely not the case. -Erik -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Free forum by Nabble | Edit this page |