Hello Thomas, thank you for your reply.
The problem we are facing is that there is no possibility to define both, NVARCHAR and VARCHAR columns within one table. We use the type OTHER now for VARCHAR columns and VARCHAR for NVARCHAR columns. With this solution we have to patch the TypeMap class to get the OTHER datatype working properly. The other issue I mentioned is that with some databases, you have to add an N in front of string literals but there is no way to configure this in the corresponding DB-class (configuration per column would be great). Therefore we patched the SQLExpression to add the N for some databases. We have to do this mixture of VARCHAR and NVARCHAR since otherwise our records could be longer than the maximum page size of MSSQL Server 2000 which is 8k. The first problem could be fixed if we had some NVARCHAR etc. data types. The second problem would be solved by providing the possibility to configure the N for every database (and there according to the type of the column). Third problem is our problem (bad database design). Bye, Tobias -----Ursprüngliche Nachricht----- Von: Thomas Vandahl [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 30. August 2007 08:17 An: Apache Torque Developers List Betreff: Re: Torque Unicode support Tobias Hilka wrote: > Do you have any plans for supporting Unicode in further releases. There > are also some other problems with Unicode (see some bugtracker entries). AFAICT, Torque works quite well with Unicode strings when using MySQL (>= 4.1) as a backend, so this might not be a general issue. I have no experience with the special Oracle data types, however. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
