Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

from 6.15 to sql

from 6.15 to sql

from 6.15 to sql

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.

RE: from 6.15 to sql

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.

Custom VB and Btrieve development.
Certified Pervasive Developer
Certified Pervasive Technician

RE: from 6.15 to sql

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,

RE: from 6.15 to sql

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).  

Custom VB and Btrieve development.
Certified Pervasive Developer
Certified Pervasive Technician

RE: from 6.15 to sql

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.


RE: from 6.15 to sql

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.

Custom VB and Btrieve development.
Certified Pervasive Developer
Certified Pervasive Technician

RE: from 6.15 to sql

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

record A           record B             record C

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.


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close