I have a client that would like me to build some reporting on top of an existing app that uses Pervasive SQL2000i. I was going to simply attack the issue by connecting to Pervasive via an ODBC layer and building some asp.net/Crystal reports, but I'm new to Pervasive, and it has me moderately confused. I've read as much as I can, but info on this old version is sparse.

I got the data from my client to test with, and there seem to be three file types for each 'table': filename.dat (it's small, under 2k, and contains some upper ASCII. Is this a 'ddf' file?), a filename.tag (seems to be just an ascii file of column names, separated by a carriage return), and a filename.btr (the actual data...these are large). The data directory contains about 40 'sets' of these files, so from what I've read, I'm guessing each set is a 'table'.

I contacted Pervasive, and since SQL2000i is off support, they wanted $500 to open a ticket..they also suggested upgrading, which isn't an option. My client's Pervasive came bundled with their app, so there's no documentation and no install CDs. I tried to create an ODBC data source directly on my clients machine to test. I setup the connection to point to the directory that contained all the .dat, .tag, and .btr files and I get the following message:

"[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine Interface][Data Record Manager]The MicroKernel cannot find the specified file(Btrieve Error 12)". (image attached)

I'm stumped. Is there something simple I'm missing and/or is there a 3rd party ODBC driver that might be another option? I really need to get this working, but I can't mess with the environment that their current app runs on (ie I can't upgrade Pervasive or get too carried away with installing stuff on their critical server due to lack of support). If anyone has any suggestions, I'd really appreciate it.

thanks,
Tec

First off, you should have some DDF files (FILE.DDF, FIELD.DDF, and INDEX.DDF at least). If you don't, then you need to contact the vendor of the application or build them yourself. Without DDFs, you will not be able to access the data through ODBC.
If you are still getting the status 12 after creating the DSN pointing to the DDFs(Dictionary path) and data files (Data Path), then you might have some hard coded paths in the DDFs. You can verify this by issuing a "SELECT * FROM X$FILE" (or double clicking on the X$FILE table) in the PCC.

Hi,
If the DDF's Files respect the structure of xtrieve with Btrieve 6.16 i can give u a .NET class source code (that i use in my applications) to read and write data into btrieve files without usinge ODBC and user directly MKE engine