Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Porting Btrieve info to Access
- Thread starter dickersd
- Start date
- Thread starter
- #2
MichaelRed
Programmer
Been there. Done that. Lot of work.
Depends on your specifics. I know of NO ODBC dreiver for BTrieve, so my aproach was to build class modules for the BTRieve tables. These were set up with an internal UDT which reflected the BTRieve table organization. My classes were set up to read one record at a time.
To build the MS Access tables, I used the same info used to build the BTRieve calss UDT's to construct a table (in Ms. Access) with the field properties. I included fields in the MS Access table for the equivalent MS Access field properties, and wrote a small procedure to update the MS Access field properties to the closest match to the BTRieve field properties.
Another procedure actually created the MS Access tables, based on the Field properties table.
Hard part done, one more procedure in MS Access. Read a record from a BTRieve table, set the corresponding MS access table fields to the BTRieve vaues and append the MS access record to the table.
Walla Walla Bing Boom Done!
Of course, IF you can afford the price of Pervasive SQL, you can get he ODBC driver, use PERVSIVE to retrieve the data, do SOME conversion and append the records to any table structure you want.
There are some data types in BTRieve which simply do not 'translate' to any standard data type in MS Access. The one which I ran across was the "packed" numerics (two 2 four ASCII Bytes representing numeric data which needed to be converted back to numeric data). These were used in some BTRieve tables to reduce the field (and therefore the Table) sizes. The closest match I know of in Ms. Access is the "bookmark", however MS. Access doesn't offer a (secrete?) decoder ring to get the numeric value(s) from the ASCII, so I had to do this seperatly (I placed the encode / decode function in the calss module).
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over
Depends on your specifics. I know of NO ODBC dreiver for BTrieve, so my aproach was to build class modules for the BTRieve tables. These were set up with an internal UDT which reflected the BTRieve table organization. My classes were set up to read one record at a time.
To build the MS Access tables, I used the same info used to build the BTRieve calss UDT's to construct a table (in Ms. Access) with the field properties. I included fields in the MS Access table for the equivalent MS Access field properties, and wrote a small procedure to update the MS Access field properties to the closest match to the BTRieve field properties.
Another procedure actually created the MS Access tables, based on the Field properties table.
Hard part done, one more procedure in MS Access. Read a record from a BTRieve table, set the corresponding MS access table fields to the BTRieve vaues and append the MS access record to the table.
Walla Walla Bing Boom Done!
Of course, IF you can afford the price of Pervasive SQL, you can get he ODBC driver, use PERVSIVE to retrieve the data, do SOME conversion and append the records to any table structure you want.
There are some data types in BTRieve which simply do not 'translate' to any standard data type in MS Access. The one which I ran across was the "packed" numerics (two 2 four ASCII Bytes representing numeric data which needed to be converted back to numeric data). These were used in some BTRieve tables to reduce the field (and therefore the Table) sizes. The closest match I know of in Ms. Access is the "bookmark", however MS. Access doesn't offer a (secrete?) decoder ring to get the numeric value(s) from the ASCII, so I had to do this seperatly (I placed the encode / decode function in the calss module).
MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question