I have a Btrieve file that I want to access using both the Btrieve API
and SQL queries. (I have an old 16-bit app and a new app that access
the same 'tables'). It looks like the SQL engine inserts an extra
byte between integer fields and char fields, so that the data don't
line up the same for the two access methods.

More specifically, I have a table with a 4-byte integer key, followed
by a 12-char field and then a 254-char field. (I've added the table to
a database.) If I insert a record using the data manager, the first
text field shows up in the 6th position in the Function Exector
utility (the second text field does follow immediately after). If I
insert a record in the Function Executor (lining up the first text
field in the 5th byte offset, right after the integer), a SQL query
"drops" the first character of the first text field and "moves" the
first character of the second text field to the end of the first.

This must be some kind of off-by-one error, but I'm not sure where to
start looking to resolve it.

Any help much appreciated.

Jim

"Jim Carpenter" <carpen (AT) wharton (DOT) upenn.edu> wrote

I ran into the same problem, I think. DDFs that I created with the data
manager modified the actual btrieve files so that they were unusable by my
DOS app. At the time I thought it was because the DDFs were created with
referential integrity constraints that locked out individual file access. I
do recall also that the field positions seemed to have moved. Anyway, I
solved the problem by creating DDFs with a third-party product called DDF
Edit which allows you to document the btrieve file structure without
changing it. You have to know the structure; it doesn't figure it out for
you. I am using PSQL 2Ki SP4.

HTH,
Brad Kunkel
Integrated Business, Inc.

carpen (AT) wharton (DOT) upenn.edu (Jim Carpenter) wrote in message news:<c4db771a.0401150741.7163c125 (AT) posting (DOT) google.com>...
This is only generically true. Pervasive.SQL from Version 2000 on has
what is called 'True Nulls'. Instead of reserving a data value for
Null, the file contains a Null/Not Null flag (one byte long).

However, in your case, since you have an existing data file, the
problem is in the DDF definitions that you created. Unless you
specifically request it, new DDF definitions are assumed to be True
Null definitions.

To create a DDF definition that does not have this problem, try:

SET TRUENULLCREATE=OFF
CREATE TABLE MyTable IN DICTIONARY USING 'C:\My_File.btr' (iKey int,
ShortName char(12), LongText char(254))
SET TRUENULLCREATE=ON


If nulls are not allowed, this may just be a DDF problem with the NULL
flag:

CREATE TABLE MyTable IN DICTIONARY USING 'C:\My_File.btr' (iKey int
not null, ShortName char(12) not null, LongText char(254) not null)


One of these methods should set the DDF to the format you need.

Brendt H