VARCHAR, LONG VARCHAR 
Author Message
 VARCHAR, LONG VARCHAR
Hi,

Dumb question:

In DB2 7.1, if a VARCHAR can contain up to 32,672 bytes, and a LONG
VARCHAR contains up to 32,700 bytes - what determines which kind of
varchar should be used (apart from an extra 28 bytes?)

Thanks,

Sent via Deja.com http://www.***.com/
Before you buy.



Mon, 28 Apr 2003 03:00:00 GMT
 VARCHAR, LONG VARCHAR

Always use a varchar if possible.  Long fields have extra processing
that can hurt performance.  (Actually, another long field - CLOB - is a
better choice than LONG VARCHAR if you can't use a VARCHAR).

To use 32K varchars, you need a tablespace and bufferpool defined with a
32K page size.

Quote:

> Hi,

> Dumb question:

> In DB2 7.1, if a VARCHAR can contain up to 32,672 bytes, and a LONG
> VARCHAR contains up to 32,700 bytes - what determines which kind of
> varchar should be used (apart from an extra 28 bytes?)

> Thanks,

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Mon, 28 Apr 2003 03:00:00 GMT
 VARCHAR, LONG VARCHAR

Quote:
> Always use a varchar if possible.  Long fields have extra processing
> that can hurt performance.  (Actually, another long field - CLOB - is
> a better choice than LONG VARCHAR if you can't use a VARCHAR).

> To use 32K varchars, you need a tablespace and bufferpool defined
> with a 32K page size.

What does this do to my table if I have other fields defined in the row?
Say, a row that has BIGINT, SMALLINT, SMALLINT, VARCHAR(32K)?

Also, would you happen to know if the DB2 Net Search Extender works
with CLOB fields?

Thanks for your response.

Regards,

Sent via Deja.com http://www.deja.com/
Before you buy.



Mon, 28 Apr 2003 03:00:00 GMT
 VARCHAR, LONG VARCHAR
Net.Search is designed to work with CLOBs.

If you have other columns in the table, each has a length that reduces the
maximum size possible for the varchar.  A 32K page allows a maximum row
width of 32677.  You calculate row width by summing the widths of all
non-long field columns.

Quote:

> > Always use a varchar if possible.  Long fields have extra processing
> > that can hurt performance.  (Actually, another long field - CLOB - is
> > a better choice than LONG VARCHAR if you can't use a VARCHAR).

> > To use 32K varchars, you need a tablespace and bufferpool defined
> > with a 32K page size.

> What does this do to my table if I have other fields defined in the row?
> Say, a row that has BIGINT, SMALLINT, SMALLINT, VARCHAR(32K)?

> Also, would you happen to know if the DB2 Net Search Extender works
> with CLOB fields?

> Thanks for your response.

> Regards,

> Sent via Deja.com http://www.deja.com/
> Before you buy.



Tue, 29 Apr 2003 03:00:00 GMT
 
 [ 4 post ] 

 Relevant Pages 

1. long & long varchar

2. Long Varchar and Long Byte

3. SQL SERVER: Varchar[130] or varchar [30]

4. changing column datatype -- varchar(20) to varchar(40)

5. VARCHAR vs VARCHAR

6. How to change varchar (40) to varchar (70)?

7. varchar(250) vs. varchar(30)

8. To varchar or not to varchar

9. Varchar 2 et Varchar

10. Replacing varchar(20) with varchar(255) in an existing table

11. How to set varchar(200) to varchar(255) on runnig database

12. changing varchar(M) to varchar(N)


 
Powered by phpBB® Forum Software