Is it possible to covert Pervasive to a Access database?

[Guest_imported]

If so then how may you go about it? If anyone has any information on where I can contact people that know how please send it my way.
[sig][/sig]

 

[MichaelRed]

I am currently in the process of doing this.

The basic approch I am using is:

I have UDT's which "define" the structure which I want for the BTRieve tables. I use a utility routine to translate these into additional UDT's for the actual BTRieve files (everthing is a string, so all numerics need to be converted to the "Fixed Length String Representation of the Numeric value --- MKI; MKS; MKL ...)

I have generated Class modules for each of the BTRieve tables from UDT's which were used to "define" the various tables. The Class Modules include property get/let functions for each of the "fields" in the BTRieve tables, as well as the BTRieve methods (First; Last; Next; Pevious; Equal; LessThen ....) calls to the necessary conversion routines (CVI, CVS, CVL) and various BTRieve functions.

I then used the same UDTs to create MS Access tables - which then have the same structure as the BTRieve files.

Here, it gets a little more complicated. In my case, some of the BTRieve files have Multiple instances, so I need to add field(s) to the MS Access table definitions for the (BTRieve) File name, and date/time stamp, where the record originated. If your structure is more simplistic, you can ignore this step.

Next, I generate a series of basCopyXXX functions which simply loop throught the BTRieve tabes and add each record in the BTRieve table(s) to the Ms. Access database table. Because I also have multiple instances of the Entire BTrieve based application, I also need to go through the exercise for each instance of the BTRieve application, so I have a wrapper program which "Sets" the Ms. Access database & recordsets, and sets the path for each of the BTRieve table sets for the class modules, sets some (BTRieve) database identification parameters and calls each of the basCopyXXX routines.

This is a fair ammount of work, and is just the beginning of th issue. Very lilttle of the "OLD" app (VB?) will translate easily into Ms. Access. Certailnly no "Forms" will be able to be imported without at least as much effort as the BTRieve tables. Unless the code used to manipulate your database is more-or-less recent VB/VBA, it will also need translation.

My purpose in accompllishing the translation into Ms. Access is to use the Ms. Access tables for the "NEW" datasource for a VB6 app, which has already been (mostly) translated from VB 1.0 to VB6 on the language side. The primary reasons for "ditching" the BTRieve tables are:

The "OLD" tables used overlapping indices, so there is NO WAY to use any of the SQL engines without re-writting the BTRieve tables, so SOME conversion needs to be done to be able to use SQL.

If I were to convert to BTRieve ver 6 / 6.15, I would still need to write some conversion routines, and - as far as i know - I would still need either a third party SQWL driver for the BTRieve Tables, or I would need to access them through (Ms. Access) ODBC drivers. Either approach would mean an additional layer of software 'in the loop'.

By just placing the data in an Ms. Access with a table for each BTRieve table TYPE. I can access the data using SQL with fewer components/layers. [sig]<p>MichaelRed<br><a href=mailto:mred@duvallgroup.com>mred@duvallgroup.com</a><br>There is never time to do it right but there is always time to do it over[/sig]