469,286 Members | 2,407 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,286 developers. It's quick & easy.

Graphic columns not allowed

Hi,

I tried to create a table that had a column with graphic data type.
The database reported that the graphic data types were not supported on
my database. I am using the DB2 v8.1. How do I turn this feature on?

Thanks

Nov 12 '05 #1
5 1716
de*******@yahoo.com wrote:
Hi,

I tried to create a table that had a column with graphic data type.
The database reported that the graphic data types were not supported on
my database. I am using the DB2 v8.1. How do I turn this feature on?

Thanks

GRAPHIC columns are only allowed for codepages which support double byte
codepoints.
That would be Unicode databases and the various asian ones.

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #2
Serge Rielau wrote:
GRAPHIC columns are only allowed for codepages which support double byte codepoints.
That would be Unicode databases and the various asian ones.

Cheers
Serge


I see. I was trying to map a table from SQL Server to DB2. The column
was defined as nvarchar type. Is that the correct mapping?

Thanks for the answer.

Nov 12 '05 #3
de*******@yahoo.com wrote:
Serge Rielau wrote:
GRAPHIC columns are only allowed for codepages which support double


byte
codepoints.
That would be Unicode databases and the various asian ones.

I see. I was trying to map a table from SQL Server to DB2. The column
was defined as nvarchar type. Is that the correct mapping?

To the best of my knowlegde NVARCHAR in SQL Server is UCS-2 (double byte
Unicode). In DB2 that would match GRAPHIC in a Unicode database.
If you have a lot of NVARCHAR flying around you may want to consider
just using a unicode. Your VARCHAR columns will then be UTF-8 and
GRAPHIC UCS-2.

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #4
Serge Rielau wrote:
To the best of my knowlegde NVARCHAR in SQL Server is UCS-2 (double byte Unicode). In DB2 that would match GRAPHIC in a Unicode database.
If you have a lot of NVARCHAR flying around you may want to consider
just using a unicode. Your VARCHAR columns will then be UTF-8 and
GRAPHIC UCS-2.


That is interesting. So, if the database's default character set is
unicode or UTF-8, then the SQL Server NVARCHAR would just map to a
VARCHAR in DB2. (I take it the same is true for other Nxyz data types
too.) That makes sense and simplifies things a lot.

Thanks a lot!

Nov 12 '05 #5
de*******@yahoo.com wrote:
Serge Rielau wrote:
To the best of my knowlegde NVARCHAR in SQL Server is UCS-2 (double


byte
Unicode). In DB2 that would match GRAPHIC in a Unicode database.
If you have a lot of NVARCHAR flying around you may want to consider
just using a unicode. Your VARCHAR columns will then be UTF-8 and
GRAPHIC UCS-2.

That is interesting. So, if the database's default character set is
unicode or UTF-8, then the SQL Server NVARCHAR would just map to a
VARCHAR in DB2. (I take it the same is true for other Nxyz data types
too.) That makes sense and simplifies things a lot.

Thanks a lot!

Yes and no. It is correct that UTF-8 and UCS-2 have the same expressive
power w.r.t. codepoints.
Things are getting interesting when you do do SUBSTR() or LENGTH().
In UCS-2 things are easy (I simply a tiny bit here by not considering
"combining charcters") since 2 bytes match 1 character - always. DB2
knows that and SUBSTR(graphiccol, 3, 5) will truly give you the 5
charcters starting with the third.
In UTF-8 things get messy. Both SUBSTR() and LENGTH() (as well as other
string operations) use bytes for their unit for CHAR. So SUBSTR(utf8col,
3, 5) can give anywhere from 2-5 characters.
So if you don't do much in the way of string manipulation (other then
concat which is harmless) then UTF-8 will be good (space efficient). If
you do string manipulation I recommend GRAPHIC (at the cost of space).

Hope that helps.

Cheers
Serge

PS: In a futire version of DB2 character based string manipulation will
be provided. But this is the way of the land as it is right now.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Lauren Quantrell | last post: by
20 posts views Thread by Joe exCSSive | last post: by
1 post views Thread by Lopezd9 | last post: by
4 posts views Thread by Jim Richards | last post: by
1 post views Thread by icepick72 | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.