Pervasive 2000 and a version 4.0 .btr file
Matthew Egen
After figuring out how to get Pervasive SQL2000 to see the data in some old
.btr files I ran into this snag: There is a table that I know has to have
data in it (the file size is 145mb) but for some reason I can't seem to get
Pervasive to see the data in the file.
Any ideas? I don't get any errors but I also don't get any data.
Thanks in advance.
-Matt
Linda
run a BUTIL -STAT against the file, does it show 0 records?
Linda
Pervasive Support
Matthew Egen
File Version = Prior to version 6.00
Page Size = 4096
Page Preallocation = No
Key Only = No
Extended = No
Total Number of Records = 701201
Record Length = 175
Data Compression = No
Variable Records = No
Available Linked Duplicate Keys = 0
Balanced Key = No
Log Key = None
System Data = No
Total Number of Keys = 1
Total Number of Segments = 1
Key Position Type Null Values* ACS
Segment Length Flags Unique Values
0 1 1 4 Integer D -- 701201 --
Thanks in advance,
Matt
"Linda" <Linda.A...@pervasive.com> wrote in message
news:3b0c4029...@outside.news.aus.pervasive.com...
Matthew Egen
reponse I got:
Btrieve Error on operation B_STEP_NEXT (24)
Btrieve status 22
"The data buffer parameter is too short."
"Linda" <Linda.A...@pervasive.com> wrote in message
news:3b0c4029...@outside.news.aus.pervasive.com...
Guy Dawson
Matthew Egen wrote:
>
> I just tried using the Function Executor to open the records and this is the
> reponse I got:
> Btrieve Error on operation B_STEP_NEXT (24)
>
> Btrieve status 22
> "The data buffer parameter is too short."
This is not important - BEFORE you try op 24 in the Function Executor
tell the Function Executor the length of the data to be returned. Its
default is too small and it uses the value from the last record as the
default for the next. If you're using variable length records it can
be a real pain.
How long are the records in the file? Specify this as the data buffer
length before you try the op 24.
Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
g...@crossflight.co.uk 07973 797819 01753 776104
Matthew Egen
function executor but still nothing in the tables. I am using the "Control
Center" and just trying to open the table. I do this by double clicking on
the table to bring up the 'SQL Data Manager'. On most tables this will
result in displaying the tables data. On this one table though it shows me
nothing and says their are 0 records.
"Guy Dawson" <g...@crossflight.co.uk> wrote in message
news:3B0E54BA...@crossflight.co.uk...
danny_dion
On the PCC:
click once on the specific table (Icon come bleu)
Right click
Task
Edit table desin
Check table location "statistic"
Check fields "Column"
Matthew Egen
guessing that means the DDF file is either bad or doesn't exist?
Arrgh!
-Matt
"danny_dion" <dd...@infopharm.ca> wrote in message
news:d177bd8e.01052...@posting.google.com...
Linda
definition for the Btrieve file, and possibly the DDF format.
Try this in SQL Data Manager:
Select * from "X$Field" where "xe$Name" = 'Xf$Id'
This should return one row - what is the Xe$DataType returned for this
row? If it's a 14, your DDFs themselves are most likely ok. If it's
a 1, then your DDFs are in an older format and need to be converted
using the CNVDDF utility you can download from:
http://www.pervasive.com/support/updates/toolbox.tml.
After your DDFs are converted, try the following in SQL Data manager:
Select * from "X$File"
Find the listing for your data file that's not showing any data. What
is the value for Xf$Loc for your table? Is it pointing to the correct
location?
Take note of the Xf$Id value for your table, and execute the following
in SQL DM:
Select * from "X$Field" where "xe$File" = <number>
and fill in the ID number for your table. Is this showing the field
definitions for your table?
Linda
Pervasive Support
Matthew Egen
error code = 0
Unable to open table: X$Field.
No such table or object."
In the Pervasive Control Center the table X$Field has a big red checkmark on
it.
"Linda" <Linda.A...@pervasive.com> wrote in message
news:3b16798e...@outside.news.aus.pervasive.com...
Matthew Egen
There are no X$ files on the media supplied by the vendor. There are
however three files: file.ddf, field.ddf and index.ddf. I can not open the
X$ tables unless I rename those files (i.e. Files.DDF to X$Files.DDF)
however when I do that then I can't see the data tables at all anymore.
Ack!
Thanks again in advance,
-Matt
"Linda" <Linda.A...@pervasive.com> wrote in message
news:3b16798e...@outside.news.aus.pervasive.com...
Antonov Alexey
Please tell me, what product can create Btrieve file of version 4.0.
If you can, please send me standard ddf files (file.ddf, field.ddf etc.) in
format 4.0.
Thank you!
Alexey
Linda
through a SQL interface, you use the table name, not the physical file
name (with the Btrieve interface, you use the file name). The
dictionary contains the information about which table names correspond
to which Btrieve files.
The dictionary files themselves (file.ddf, field.ddf, and index.ddf)
are supposed to be defined as tables. Their table names are X$File,
X$Field, and X$Index, respectively. So, if you log in to any
Pervasive database, you should always have these tables defined. You
should always be able to do a "Select * from X$File". Try it against
Demodata.
If you can't do Select statements against the system files, then you
have an improperly formatted dictionary, and you're going to have
other problems down the road... Try going in to PCC, right click on
your database name, and select Tasks/Check Database. Do a
Consistency Check on all tables. If the system tables don't pass,
your DDFs aren't going to work properly.
Linda
Pervasive Support
JohnR
I'm sorry, but I have to start with a bit of background.
A Btrieve version 4.0 file can be made by any version of Btrieve or
Pervasive.SQL back to Btrieve v4.0. Btrieve v3.0, 4.0, and 5.0 files
are essentially the same except that each successive version allowed
additional features. For example depending on which features were used
a Btrieve 5.10a workstation engine could create a Btrieve v3.0 file.
That being said, there were substantial improvements made in file
format when Btrieve 6.x was introduced and I always recommend that no
one run a prodution database in 5.0 or earlier format. Btrieve v.50
and earlier used a data integrity algorithm called pre-imaging in
which the engine created a *.pre file that contained extra pages
needed to do inserts and updates to the main file. This meant that
there was a good deal of extra and unnecessary file I/O being
performed and the window for having a problem while doing a write was
larger than necessary. It also can lead to dreaded Status 14s if the
pre-image files are damaged or deleted. The usual way to get to your
data back after a Status 14 is to use a hex editor to toggle some bits
in the main data file which is never advisable in any database file.
Btrieve v6.0 (introduced in 1991 - so 5.0 and earlier are mid 1980's
technology) and later uses a technique called shadow paging in which
those extra pages are contained in the data file itself (which is why
6.0 files are usually larger than 5.0 files) and are continuously
allocated and reused as necessary. It is highly recommended that
Btrieve v6.0 file format or later (7.0) be used in all production
databases. I like to use a current and supported database engine for
anything I do, but for those who insist they need a royalty free
engine and don't mind using Btrieve 6.15 (providing they have
purchased and own the 6.15 UDL from Btrieve Technologies, Inc. so they
aren't using the Btrieve 6.15 engine without a license) they should
always use 6.0 file format IMHO. This is easy to do because
Pervasive.SQL (both 7, 2000, and 2000i) are as close to 100% backwards
compatible for both Btrieve applications and data as is humanly
possible. I personally have spoken with programmers who ran Btrieve
1.0 applications on Pervasive.SQL 7 (and yes they knew Doug and Nancy
way back when :-).
On the second issue - DDFs. There is really no way to "send standard
DDFs" to anyone because the DDFs contain the metadata or schema for
the Btrieve files. Btrieve files themselves only contain a portion of
the complete metadata for any database. You can do a "butil -stat" and
get all the metadata that are in the files themselves. This consists
of the # of records, the page size, the index types, and various
attributes of the file and indexes. The part that is conspicuously
missing is the data type of the non-indexed columns. This information
is actually contained, as code, in the application itself so it is not
necessary for the data files themselves to contain this info. This
means that the Btrieve application that creates and populates the data
files doesn't need DDFs, but any 3rd party application that doesn't
have that information coded into it (usually relational applications
like Access or Crystal) does need DDFs. It also means that the
programmer or company that created the original application and has
the complete file layout is the best and sometimes the only one who
can create proper DDFs. It is often possible to reverse engineer DDFs,
but it can be a challenging, tedious, and daunting task. There were
several 3rd party applications like DDF Builder/Sniffer from Smithware
and DDF Maker that made this task easier, but those tools create DDFs
in the old ScalableSQL 3.0 file format which doesn't work well with
Pervasive.SQL. Also since those tools created the DDFs via the Btrieve
interface all maintenence was manual (in other words if you change the
data file you have to go in and change the DDF seperately) and they
often introduced errors into the DDFs. Fortunately, if you have old
DDFs there is a conversion utility posted on the Pervasive site, and
the PCC has a Database consistency checking Wizard that will tell you
if your converted DDFs actually match the data files and it will list
all the problems with those files it finds so you can fix the DDFs if
you have the skill and patience.
In short, there is no such thing as "standard DDFs" unless you mean
empty ones which will do you very little good and it's probably not a
very good idea to be working with Btrieve v4.0 files in a production
environment. I know this is not very good news, but I hope it helps
clear things up a bit.
JohnR
Matthew Egen
utility or some such?
Unfortunately since the data files are provided by a third party we don't
have any control over the database. :(
Thanks again
"Linda" <Linda.A...@pervasive.com> wrote in message
news:3b1cee8c...@outside.news.aus.pervasive.com...
Bill Bach
newer databases. They should be interested in fixing this issue, since it will
help all of their sites.
Building the DDF's yourself is not a chore for the queasy, since they can take
a lot of work. If the data file definitions are OK but the system tables are
just bad, then you may be able to export the definitions from the existing set
of DDF's and put them into a new one by selectively copying records from one to
the other. However, this must be done exactly correctly, or the resulting set
will be useless.
Of course, if the DDF structure itself is bad, how much can you trust the data
definitions themselves?
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
Bill...@compuserve.com
www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: June 19-22, 2001 - See our web site for details!