>> one compelling reason would be that they travel in full-length

between

>> server and client. :-(

That's compelling enough for me. Do you know why that is? If I have a
type that may vary in length from say 100 characters to 10k characters,
it has to send a 10k buffer across? I don't get it. Is this the case
even with Firebird?

We want to store registry paths, which can be arbitrarily long.
Unfortunately, you can't index on a blob so a lookup on a path could
take a long time.

I think what we will do is create a size limitted varchar for user
collation, indexing, searching, and displaying. The raw complete name as
a BLOB, and a hash of the complete string for lookup by the underlying
implementation (which needs to find a row using the entire,
non-truncated path). Hmmm....any other suggestions?

R.

-----Original Message-----
From: Nando Dessena [mailto:nandod@...]
Sent: Wednesday, March 12, 2003 10:52 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] VARCHAR size


Robert,

R> Is there a reason not to simply specify all VARCHARs to use the max
size
R> in Firebird?

one compelling reason would be that they travel in full-length between
server and client. :-(

R> Since VARCHARs by definition only use as much space as
R> necessary to store a string (the length of which is stored in the
first
R> two bytes), why does VARCHAR even take a length parameter?

maximum length is a domain attribute before it is an implementation
constraint. You want to specify that a certain data item has a maximum
length of x, just to express a business rule.

Furthermore, you also want to know what this maximum length is in your
code, for declaring static buffers, etc. Having a piece of code cater
for 32K when
it really can't receive more than 16 bytes can be wasteful and
deceiving, IMHO.

Ciao
--
Nando mailto:nandod@...