Results 1 to 12 of 12
  1. #1
    Join Date
    Mar 2012
    Posts
    3

    Red face Unanswered: Legacy Btrieve Data access via ODBC...

    Hi All,

    I've been attempting for a few days now to gain access to an old mid-90's application data so I can do a conversion on it.

    The system is called OHM and seems to be using Btrieve 6.15. I have managed to used its setup program to remove the "user name" encryption/protection off the files, and it helpfully also has the option to "Create DDFs for Third Party ODBC Tools".

    This generates a number of DDF files: INDEX.DDF FILE.DDF FIELD.DDF
    From the reading I have done I should now magically be able to point Pervasive Workstation v11 at this directory of the three .DDFs, multiple .DAT and .LCK files and everything will 'just work' so I can get to the data via ODBC... no luck though!

    I can create a Pervasive ODBC Engine Interface, DSN = TEST, Create a database name TEST, integrity enforced = on, Dictionary + Data file locations = the .DDF and .DAT dir (same). Testing this connection says it's OK.

    Now in Pervasive Control Center (not strictly SQL from what I can work out but I should be able to see everything) I see the 'TEST' database and under 'Tables' I see all the .DAT files listed. When clicking on one to try and see its contents I get:
    [LNA][Pervasive][ODBC Engine Interface][Data Record Manager]No such table or object.

    In the query window the text
    select * from "EMPLOYEE.DAT"
    is shown.

    My understanding (from the example database) is that there should be a table name beneath that, but I'm not shown anything, I can't expand it.

    Has anyone got any pointers for how to get this working?

    Unfortunately this is medical data so I can't give copies to people to peruse.

    Thanks in advance for any assistance!

  2. #2
    Join Date
    Mar 2012
    Location
    Somewhere In Europe
    Posts
    24
    Hi
    I has a bit experience in btrieve/pervasive db's (about 10 years).
    The first of all, Perv v. 11 doesn't work with old btrieve databases, versions to 8.6 (as I remember) used IPX protocol for communication. All later versions use TCP.

    Try to find any trial version older o equal 8.6, install and configure (remember to set "create file version" = 6.x). For simple exploration the best tool is ddf periscope (not from Pervasive), of course you can create odbc source.

    Regards
    Mike

  3. #3
    Join Date
    Dec 2001
    Posts
    1,109
    Provided Answers: 4
    @mar2012,
    If you don't see tables listed in the database in PCC, it's possible the process to generate the DDFs didn't work properly.
    If you expand the "System Tables" node, do you see x$file listed? Can you open that table? Does it show your tables listed or does it show an error?
    Can you post just the DDFs (FILE.DDF, FIELD.DDF, INDEX.DDF). They won't have any private data. I don't want your data files.

    @Mikefox1207,
    Actually, Btrieve never supported IPX. It supported SPX and still does as well as TCP/IP. PSQL v11 can read any format of Btrieve file going back to Btrieve v4. It can only write to v6 format files though but gives a status 46 (access is denied) on pre-v6 files.
    Mirtheil Software
    Certified Pervasive Developer
    Certified Pervasive Technician
    Custom Btrieve/VB development
    http://www.mirtheil.com
    I do not answer questions by email. Please post on the forum.

  4. #4
    Join Date
    Mar 2012
    Location
    Somewhere In Europe
    Posts
    24
    Hi Mirtheil

    You are partly right, it's spx, however as I remember if you set IPX internal network number to 0, btrieve requester returns 91 (95) status to the application, so I wouldn't use sentence "Btrieve never supported IPX".

    I finished my adventure with Pervasive on version 8.6, then I heard that Pervasive is going to abandon support for 16-bit applications. Give them glory if they're still doing it.

    Regards
    Mike

  5. #5
    Join Date
    Mar 2012
    Posts
    3
    [QUOTE=mirtheil;6543919]@mar2012,
    If you don't see tables listed in the database in PCC, it's possible the process to generate the DDFs didn't work properly.
    If you expand the "System Tables" node, do you see x$file listed? Can you open that table? Does it show your tables listed or does it show an error?
    Can you post just the DDFs (FILE.DDF, FIELD.DDF, INDEX.DDF). They won't have any private data. I don't want your data files.

    @mirtheil and @Mikefox1207
    Thanks for the responses, I've attached a screenshot. It doesn't look right to me, most of the Xf$Name column is blank, as if the application hasn't generated it correctly.

    I have been given a firm no to sending any of the files (even generated metadata) outside the corporate firewall as it's health data under HIPAA etc and even the possibility of any leakage is unacceptable (think: being fired, then shot), if it was raw text fine, or screenshots, but no binary data.

    I have been looking without success for a Btrieve 6.15 ODBC driver (I've heard of version 2.04? which was buggy for multithreaded applications but worked) but any URLs for it have long since died (10 years is a long time on the net!). Does anyone have a hint for me where it might be available? I guess it would be worth a shot trying it...

    Thanks again for your assistance.
    Attached Thumbnails Attached Thumbnails 26-03-2012 10-50-20.png  

  6. #6
    Join Date
    Dec 2001
    Posts
    1,109
    Provided Answers: 4
    I have never, in almost 17 years of working with Btrieve / Pervasive, seen a set of DDFs like that. It appears that the program that generated the DDFs failed. The XF$NAME is the table name and the XF$LOC is the physical file name.
    The DDFs have two extra DDFs that give a hint as to how they were created. The COMMENT.DDF and FIELDEXT.DDF were created almost exclusively by Smithware DDF Builder or Smithware ActiveX controls.
    Can you open the FILE.DDF using Function Executor and scroll through the records to see if there's any difference? Another option would be to use BUTIL -SAVE on the FILE.DDF. It'll generate an unformatted file where the binary data would be encoded but the string data would be valid.
    ODBC 2.04 had a number of problems including the multi-threaded issue. I haven't seen it available in a long time. In any case, if the DDFs are as you posted, even ODBC 2.04 won't be able to use them.
    Mirtheil Software
    Certified Pervasive Developer
    Certified Pervasive Technician
    Custom Btrieve/VB development
    http://www.mirtheil.com
    I do not answer questions by email. Please post on the forum.

  7. #7
    Join Date
    Mar 2012
    Posts
    3

    Smile

    @mirtheil
    I think you are correct, I thought it looked broken and you agree. I don't want to spend any more time going down this path as I think it is a dead end.

    I have found an export option in the setup program that spits out a file in this format:
    Code:
    OHMArchive
    Source:OHMWIN
    Version:20050528
    Date:03/26/2012
    Time:130450
    
    Table:ABSLOAST
    REC_NUM:2
    CODE:A
    DESCR:Approved
    INACTIVE:n
    
    Table:ABSLOAST
    REC_NUM:3
    CODE:D
    DESCR:Denied
    INACTIVE:n
    etc

    I am going to code up a python script to parse this file and spit it out into a SQL load script that I can feed into SQL server directly or as load files, thus making this issue go away

    Thanks for your help in determining the brokenness of the app database export and the futility of trying to get ODBC going!

  8. #8
    Join Date
    Oct 2013
    Posts
    2

    OHM 1990's Btreive database

    Hello,

    Sorry this is off subject.

    We use a database called occupational health manager for record retention of medical tests. Looking for a programmer who can design a tool to export that information into Access or similar. We are limited in the reports we can do with OHM windows and it is no longer supported by the company that was bought out. Any help here would be much appreciated.

    Bob Ewing
    Onsite Medical Service Inc
    Onsite Medical Service ? Industrial Health & Hearing Testing in Minnesota, Wisconsin

    Thank you!

  9. #9
    Join Date
    Dec 2001
    Posts
    1,109
    Provided Answers: 4
    @oms,
    Do you know what version of Pervasive / Btrieve OHM uses?
    Do you have DDF files (FILE.DDF, FIELD.DDF, INDEX.DDF)?
    There are programs already that I can suggest depending on the answers to the questions above. If a custom program is needed, we can discuss options.
    Mirtheil Software
    Certified Pervasive Developer
    Certified Pervasive Technician
    Custom Btrieve/VB development
    http://www.mirtheil.com
    I do not answer questions by email. Please post on the forum.

  10. #10
    Join Date
    Oct 2013
    Posts
    2

    OHM 1990's Btreive database

    Mirtheil,

    I am not real tech savvy but believe it is version 6.15 and it has a utility to create Create DDFs for Third Party ODBC Tools. The OHM version is 5.95

  11. #11
    Join Date
    Dec 2001
    Posts
    1,109
    Provided Answers: 4
    @OMS,
    I've sent you a PM.
    Mirtheil Software
    Certified Pervasive Developer
    Certified Pervasive Technician
    Custom Btrieve/VB development
    http://www.mirtheil.com
    I do not answer questions by email. Please post on the forum.

  12. #12
    Join Date
    Jan 2014
    Posts
    1

    ODBC Connections to OLD Btrieve 8.60

    Hello;
    I came across this post and it seemed like it might be the closest thing to my needs. If it should be moved, by all means...

    Okay, so here's the scenario...

    I work for a hospital, who has a clinical system that is running Pervasive SQL. The hospital has a support contract (with a huge clinical software vendor), who is ignoring our requests to modify their software. There are 4 participating hospitals in the region in the same boat. We need to modify a few elements that the system has to maintain, so that these clinical results can be shared in a regional repository. Unfortunately, the vendor doesnt want to support the change without huge sums of money, and are encouraging that each hospital purchase a new version. Suffice to say thats not a realistic ambition because these are publicly funded hospitals.

    Regardless, I should be able to see whats in these data files and potentially build a solution myself (Im a developer familiar with c,c++, java/javascript, c# asp.net etc.)...so Im thinking I should be able to build a solution myself.

    what I've learned is that these .DAT Files are really actually just BTrieve 8.60. Okay, so I hunted down some utilities and came across two sites (however, Im not sure what I will need exactly). Drive Btrieve at Odbc Software Informer
    and
    Btrieve development tools

    The second one has applications from the 90s, and I wouldnt even think its possible to get these registered (some only work with a registered copy :s).

    So, I'm trying to accomplish the following.
    1. Based on an external trigger, execute some code in a foreign application (asp.net or javascript would be excellent) that will insert some data, namely one unique identifier.
    2. On a second trigger (at a later time) execute some code that will retrieve that unique identifier .

    Where do I start? Are there ODBC java drivers for these connections? If so, would I build something like Netbeans or eclipsys, maybe .net drivers and visual studio ?

    Based on what I read here, it seems I need to create .ddf files that help to index the tables for newer 3rd party tools? Are there free tools for this, I found some kind of wonky ones on the second link I posted.

    The Pervasive environment is 8.60 with Pervasive Control Center; (I cant see any databases from that management tool, but I have been able to open records in .DAT files with some of the legacy apps and those apps also tell me the version is Btrieve 8.60.

    any help would be awesome. Also, if for whatever reason I cant get this to work, where would I find a btrieve programmer in Canada?

    Thanks!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •