Hello!
Is it true that Btrieve fields are allways stored at maimum length in
the physical Btrieve-file?
We switched form fixed length types like char (100) to variable length
like varchar (100).
The file size remains the same, even if the contents of the fields is
smaller or NULL.
Thanks in advance

Btrieve files have a fixed section where the indexes are required to
reside and any other fields that you want in that area and then you can
set the file up for variable length records where you could pack fields
by using data types that allow for this. If all you are doing is
changing data types within the fixed length section of the file then it
will not make any difference as the space is already allocated.

The bad part is you will not be able to create DDF files for packed
fields in the variable length section of the file which means you will
only be able to use the API. Packing fields goes back to the time when
disk space was a premium. It is no longer the case. I would not pack
fields in the variable length section of the file as it limits you for
the future.

Just my thoughts,

Gil

pklauss wrote:

A CHAR(100) and a VARCHAR(100) field are different data types
altogether, and in fasct, the VARCHAR field will be one byte longer.

The CHAR data type is designed to be fixed-length, with space padding
to the end of the field. It was designed for use with BASIC and other
such languages. The VARCHAR data type is null terminated (thus the one
extra byte for the null byte) and any bytes past the null are
insignificant and ignored.

If you truely want to shrink the file with lots of text strings in it,
then the LONGVARCHAR is the data type you want. However, as Gil points
out, working with these data types can be a trick, especially if you
need both Btrieve and SQL access methods to work easily. (LONGVARCHAR
works fine from SQL if you define it from SQL, but the Btrieve stuff
can be a bit of work.)

People used to use the NOTE and LVAR data types to do something similar
-- just at the end of a record. However, these types have been
deprecated and we do not recommend usig them, as you must have a PSQL7
database engine available to create the DDF's correctly.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - 03/2007 ***

pklauss wrote:

Thank you Bill and Gil !

Sorry, but I find your answers a bit contradicting.
Did I get it right?
Gil points out, that there a different portions od the record for fixed
and variable length fields and the files can only be acessed via API,
while Bill says LONGVARCHAR should do.
We only need SQL.
Thanks for reading!

Gil is talking about file internals. Yes, fixed length field types and
variable length field types are stored in different physical locations
in the datafile.

Gil suggests using a propriatary format to pack multiple fields into a
single variable length part of the record. From a Btrieve point of
view this is a logical step. From the SQL point of view you're better
of with the method Bill proposed. The LONGVARCHAR and related types
are a build-in method to do exactly the same thing. As a plus it will
show you the extracted fields in the SQL result whereas with Gils
solution you'll have to do this yourself. Just one downside: each of
the new variable length field types will require an extra 6 bytes
overhead. You shouldn't use it for just every field therefore and as
Gil points out correctly: you cannot use it on an indexed field.


On 14 Nov 2006 06:06:50 -0800, "pklauss" <klauss (AT) atelion (DOT) de> wrote:


Gordon Bos
Q-RY Solutions
+31-(0)15-2564035

http://www.q-ry.nl/