Yeah, I would think this has to be abstracted in the JDBC layer. Dov, do you have any specific problems that make you believe that this is broken?

Andrus


On Sep 19, 2006, at 5:20 PM, Tore Halset wrote:

Hello.

We are using MS SQL Server with cayenne. nvarchar works with the old (have not tried latest as we moved to jtds) ms jdbc driver and jtds without problems. Perhaps the prepared statement handles it automatically as cayenne creates prepared statements?

 - Tore.

On Sep 19, 2006, at 23:12, Dov Rosenberg wrote:

We are using Cayenne for some web services alongside our EOF based
application. Our application supports unicode formatted characters in the database but in order to support it properly using MS SQL Server apparently
we need to change our data types from char, varchar, text to nchar,
nvarcahr, ntext. This is no big deal. However in order to properly store the data into those fields and to be able to query against them we need to preface all of the strings with a N – this signals MSSQL Server to use the
Unicode encoding for that column. For example say we have a table:

CREATE TABLE "CONTENTDATA" (
    RECORDID    NVARCHAR(64)        NOT NULL ,
    XML         NTEXT               NULL ,
    CONSTRAINT PK_CONTENTDATA PRIMARY KEY (RECORDID)
);

In order to insert unicode characters into that table I need to generate a
SQL statement like:

INSERT into CONTENTDATA (RECORDID, XML) values (N’1234ABC’,
N’<MYXML>....</MYXML>’);

Notice the N in front of the strings I am inserting. In order to query on this table properly I need to add the N in front of the WHERE clause pieces
such as:

SELECT * from CONTENTDATA where xml like N’<MYXML>%’;

I only need to put the N when the data contains unicode characters – but I
really won’t know that so I probably need to do it all of the time.

I am looking for the correct place in both cayenne and EOF to add the N’ to the queries (INSERTs, and WHERE clauses). Any help or suggestions would be
HIGHLY appreciated.

BTW – it seems that Oracle can at least tolerate this unusual SQL format.
MSFT says that it is SQL 92 compliant but I haven’t found anything
documenting it yet.



--
Dov Rosenberg
Conviveon/Inquira
Knowledge Management Experts
http://www.conviveon.com
http://www.inquira.com





Reply via email to