On Wed, 21 Feb 2007, Tobias Hilka wrote:
...
We now patched the SQLExpression class to work with unicode correctly. Are
you in general aware of the problem with unicode? Are there any plans to
solve this issue in the upcoming RC2? We could provide a patch for this
class.
RC2 is nearly out. There is a fixed SVN revision which passed the vote and
unless something bad happens this will be released as RC2. It does not
contain a patch to the unicode problems you have raised.
The reason for this is that I am not sure how to proceed there. I do not
know whether the "prepend an N" solutions you have given work for all
databases supported by Torque. I am also not sure at all which is the way
torque should go in the problem with upper(). In my opinion, this is a
problem of the database. E.g. If I remember correctly, in Oracle one can
change the locale in the database to influence the way how upper() acts on
Umlauts, but I did not have the time to research this. If this is the case
and we try to enfore a specific behaviour in Torque, we loose the
opportunity to handle this in the database.
I have no idea whether the situation is the same for MSSQL.
Regarding TORQUE-70, I have no idea how to implement a solution
in a clean way. If you do have an idea, please append a patch to the
issue. Note that prepending an N to the escape character may not be the
right thing to do for all databases.
Another problem we had some weeks ago was the limit/offset problem with
MSSQL. We also found a solution for this using inner select statements. We
could also provide a fix for this issue.
We are certainly interested in this. Please create a jira issue with the
patch. I have no access to a mssql system and thus can not check the
patch, put perhaps Greg finds some time to check it.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
