Database (or tables) missing from Pervasive Control Center

[wuzzel]

Hello Pervasive lovers out there,

I have been browsing this forum all day, and my liking for PSQL is growing by the hour, but i have not yet found an answer to my problem:

Either a load of tables is missing from the database as i see it, or a database is missing from the databases tree.

A client of mine has this application called Agro-IT, running against a Pervasive 2000i server.
In the PCC i see one single database for this application, and in it i discovered a table listing all tables in the db, with pointers to files on disk.
When the application is busy, i can see datafiles change that are not referenced by any values in this Xe$Files table.
So: either the Xe$Files is incomplete, or the database-tree has a node missing.
Who will tell?

Any ideas from anyone will be much appreciated by me and my revered customer.
Thanks for reading all this,
Daan

 

[mirtheil]

It's very possible the X$file is incomplete. I've seen some applications that do not define all tables in the DDFs. If this is the case, you'll need to go to the vendor to get DDFs that accurately and completely describe all of the data files.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician

http://www.mirtheil.com

 

[wuzzel]

Hi Mirtheil,
With all due respect, that's really a drag.
But, suppose i do get the complete ddf's, would the Xe$Files - table show more entries after that?
Otherwise: how could the original ddf's be of use? I would think that the ddf files will change over time and the originals could possibly miss out on things. (For instance: views i created)

Thanks, sincerely,
Daan

 

[mirtheil]

You're right. An application vendor that doesn't define all of it's data tables in the DDFs is a drag.
There's no XE$FILES table. There is an X$FILE table and an XE$FILE field (in X$FIELD). The table names and locations are stored in X$FILE. X$FIELD has the field definitions (offset, data type, field name, etc) and is linked back to X$FILE. X$INDEX stores index information related to the X$FIELD table.
Views are actually stored in X$VIEW. If you create a view and then update the DDFs from the vendor, you will lose your views. Typically the DDFs don't change after the development cycle (once they are in the end user's hands).


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician

http://www.mirtheil.com

 

[Linda84]

A little more info...

There are many different access methods for manipulating data in a Pervasive.SQL environment. Most access methods require schema definitions, which are stored in the DDFs. However, the most basic access method called "Btrieve access" or "transactional access" does not require DDFs. An application written using the Btrieve API is expected to know the layout of the data files, and manipulates data at the record level, rather than using SQL concepts like tables, columns, etc.

Given that Btrieve API access is the oldest, and usually fastest, method available to Pervasive.SQL developers, there are thousands of applications written with it. Many of these applications, over the years, have added releational access to some or all of their data, by providing DDFs, but it's not a requirement for their base application to run.

So, that's why you might have an environment with no, or incomplete DDFs. Or, as we often see, DDFs that do not accurately represent the data.



Linda
Pervasive Software

 

[wuzzel]

Hello Linda,
Thank you very much for responding, this may just help me out.
So if i'd learn how to use a Btrieve API i might do anything to these data without having any notion of a database containing them data?

If my client still has budget, he may well be interested. (I spent two days studying the system with only very little results for him.)

Thanks again,
Daan

 

[Linda84]

Yes - the Btrieve API accesses the data file directly and works at a record level. Read a record, insert/update/delete records, etc. You still need to understand the schema so that you know how the record is constructed, but it's built into the application instead of external DDF files.

The information in the Programmer's Guide about the Transactional Interface might be helpful for you to review:

http://www.pervasive.com/library/docs/psql/950/prog_gde/prog_gde-07-02.html

Linda
Pervasive Software

 

[grnelson]

If you need to analyze the other Btrieve files and create DDF entries you can try BtSearch at

http://www.nssdd.com.

As mentioned by Linda you will still need to know the file layout even if using the API directly. Since Btrieve files can contain any type of data including binary data you need to know the data types so you can properly convert the data.

Gil

 

[wuzzel]

Well Linda, Gil, these seem fine suggestions to me,
I downloaded BtSearch and i will dig into it when i have the chance again.
Mirtheil, big thanks to you too for sharing your views.

I have learnt a lot more about the data in question. Since i do know the files' locations, i can fool Crystal Reports into at least reading the data for me, and to some extent display their data types.
That should help in creating a little application.

I think i can close the issue with all this - if not: i know where to find you now.
Sorry for misspelling X$File, it's just all so dazzling.

Cheers, hope i can return a favor sometime,
Daan