from 6.15 to sql

[BSkorepa]

I am maintaining an old C-application using Btrieve 6.15.
Files are generated and accessed directly by the application
via the BTrieve-API.

What steps do I have to undertake to switch over to SQL?
(SQL is new for me, but I am familiar with the Btrieve API)

I have heard something about DDF-files.
What are they, where can I get information about the topic?

Thanks, Bruno.

 

[mirtheil]

Changing an application from Btrieve API to use ODBC, is going to be a re-write of the application (At least the data access logic). If you are talking about moving from Btrieve v6.15 to Pervasive.SQL 2000i, your app shouldn't need to change nor should your data files.
DDFs are Data Defintion Files. They are used by the ODBC engine (and OLEDB and ActiveX) and describe the underlying Btrieve data files. The DDFs effectively list the fields and indexes of the tables. They should accurately and completely describe the Btrieve files. You can find some information on them at the

http://www.pervasive.com.

info@mirtheil.com
Custom VB and Btrieve development.
Certified Pervasive Developer
Certified Pervasive Technician

 

[BSkorepa]

Thanks for the quick answer!

My situation is as follows:
About 6 months ago I took over an old 16-bit app using Pervasive 8 and the BTrieve API for access.
To be able to debug the application I had to step back to 6.15 (in my development environment), whereas users stayed with ver8.
(The 16 bit Borland compiler crashes when using ver8)

Now that I got to know the app and BTrieve we want to enhance it and port it slowly to 32 bit.
The app is buggy for several resons, but and one reason is, that the BTrieve database is only a set of files, not a relational database.
On Manipulating data within crosslinked Tables one has to do all the logic oneself.
Thats the reson we want to go SQL.

Does this mean we have to use ODBC?
Some time back I used DAO to access a database because I was told that I should use ODBC only if there is nothing else available (On e reason as far as I remember was, that apparently on inserting a new record ODBC does not return the key, but you have to search for the record right away).

What we want is retrieving records using SELECT-statements.

Any hints would be appreciated,
Bruno.

 

[mirtheil]

What version of Pervasive 8 are you using? Last I saw (last week), it was still in RC form and hadn't been released yet. I would be cautious of using a beta software in a production environment.
You are correct in that using the Btrieve API, you are not using a Relational interface to the data. You would need to use ODBC or OLEDB to issue SQL statements. However, I would limit the use of the SQL statements to reports and the like. Performance will be better if you use the Btrieve API and SQL for what they're designed for. SQL is designed as a reporting tool. It's not designed to be used for transactions. For transactions (inserting data, retrieving a specific record, etc), Btrieve API will win hands down in performance.
In terms of using a 16bit compiler with V8, I've never tried it but it really shouldn't be any different than with 6.15 (if you're using the 32bit version of Btrieve 6.15). info@mirtheil.com
Custom VB and Btrieve development.
Certified Pervasive Developer
Certified Pervasive Technician

 

[BSkorepa]

I just talked to a technician, it is Ver. 7.9 they are using.
When I took over the development environment (Borland C++ 4.5, 16 bit), there was only a release version, no debug version. First thing I did was to create a debug version, and second thing was to find out, that the program would hang at the first BTrieve call.
At a pervasive newsgroup we were told that this is a known issue, and I was told that debugging a 16 bit program, using a 16 bit compiler under win2000 should be possible with BTrieve 6.15.
Thats the reason why I am developing with a 6.15 db (with all the drawbacks involved) whereas users have 7.9.

As far as transactions go:
With BTrieve you have to program everything yourself, right?
So how do you ensure data consistency?
Because our app has a lot of flaws with lost and garbage data.

Bruno.

 

[mirtheil]

The best way to ensure data consistency is to make sure that your app only allows proper data to be inserted into the database. In terms of Btrieve, when data is inserted, the Btrieve engine will not check it for consistency (because the insert takes a buffer of bytes). WHat that means is that if garbage is passed to the Btrieve API, then garbage will be stored. ODBC/SQL is a whole different situation. ODBC (Microsoft's layer, not the Pervasive driver) does some data consistency checking (dates, field length, etc) but the developer should still validate the data before sending it to the database. info@mirtheil.com
Custom VB and Btrieve development.
Certified Pervasive Developer
Certified Pervasive Technician

 

[BSkorepa]

Thanks.
I am aware of that.
What I mean with consistency is as follows:

record A record B record C

unique_key
field_1
.......
PTR_to_B -----> unique_key
...... .......
field_n fields_in_B
...
PTR_to_C -----> unique_key

If you have a couple of tables linked (and in fact we have more than 150) it is very errorprone if you have to take care of all the links "by hand".
So I just wondered if there is a better alternative.

Bruno.