 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Conversion / April 2005Unknown Data File Type
I am not sure if I will get anywhere with this, but this is my last ditch effort. I have a customer that is looking to convert from an old custom made DOS database program to Access (possible SQL Server). The customer has existing data in the old database files and would like to retain this data in the new database (again, Access or SQL Server). The problem is, I can not find any way to read the data and extract it into any usable type. While the data files have the MDB extension, they do not appear to be Access files. I have tried to open the files using all version of Access I have (from 97 to 2003) and none seem to work. In looking at some of the code the original DOS developer used to 'archive' some of the data, I see that he used the following to create the files: OPEN "jbarc99.mdb" FOR ISAM jobrecord "jobs" AS #2 Now of course this looks like normal BASIC code, but I have never heard of ISAM before and can not find any supporting information that helps me find a solution to my problem. Also, when I look at the datafile's BINARY, I do see references to 'MSysRelationships' so I would like to believe that these files are some sort of relational data files. If there is anyone out there that might have some ideas or be able to review the files, I would be extremely greatful. Thanks in advance, Jack C. Brinegar Innovative Software jcbrinegar@iss-c.com Hi Jack, Instead of trying to open the files with Access, have you tried importing or linking the tables they contain? The facts that the files have the .mdb extension and contain the string MSysRelationships make me feel that they may belong to an antique version of Access or Jet. I'm assuming that you'd have noticed if the files contained simple binary records (like .dbf files or custom data files created by Basic or Pascal file I/O): this is another reason to think these are "structured storage" files, which weren't common among DOS databases. If importing/linking doesn't work, I'd try writing some code against the DAO 2.5 object library to instantiate a DBEngine object and use that to open the .mdb file. Failing that, ask round for someone who still has Access 2.x installed. ISAM stands for indexed sequential access module or some such and has to do with data access technologies. Access/Jet still uses ISAM to access data in Excel sheets, text files and (IIRC) dBASE and Paradox files. It seems reasonable that there should have been an ISAM extension to the Basic file I/O statements. Have you googled for something like open "for isam" basic database ? Finally, if you have the old application, the data, and the source code, surely you can write a little routine to export the data to text files or some such? >I am not sure if I will get anywhere with this, but this is my last ditch >effort. [quoted text clipped - 29 lines] >Innovative Software >jcbrinegar@iss-c.com -- John Nurick [Microsoft Access MVP] Please respond in the newgroup and not by email. John, I have tried linking and importing. I have even tried writing a program using the earliest version (that I have) of DAO, RDO and ADO. None seem to work... I always get the same error...unrecognized file format. This has to be a database file of some sorts as I see section that identify COLUMNS and rows of data. My only concern is that if I extract the ASCII data while viewing the BINARY of the file...I might miss something of importance to my customer. I don't have access to the source code or the code-slinger that did the old program. So that is not an option either. The earliest version of Access that I have is 95,,,and that too fires the error mentioned above. I am at a loss I guess and while I hate to admit defeat...I think I have to here. The customer will not be too happy with having to re-key the data. Thanks again for your help. If you can think of anything that might be help...please let me know. Jack C. Brinegar Innovative Software jcbrinegar@iss-c.com > Hi Jack, > [quoted text clipped - 62 lines] > > Please respond in the newgroup and not by email. It's not time to give up yet, assuming the client is willing to spend some money. Obviously there's a trade off for the client between the respective costs of data recovery, re-keying the data, and leaving the data in the hard copy that must exist if re-keying is a possibility. Data recovery: there are firms that specialise in this, and they need to know about obsolete formats as well as damaged disks. They're not cheap but they'll give you a quote first so the customer can decide if it's worth while. The name Vogon comes to mind, though I've never had to use them myself. If you decide to mine the files yourself, remember that there may be numeric fields in binary formats (integer, long, double etc.) as well as in the form of strings of numerals. A bigger problem is likely to be variable length text and memo fields that are separated from the tables they belong to (i.e. a pointer in the record in the table gives the address of the data in the memo field, or an offset into a table of addresses. And if the data has been edited in the file, the tables may be fragmented. It's not easy to reverse-engineer that sort of thing if you don't do it every day<g>. Re-keying: investigate OCR of the hard copy first. >John, > [quoted text clipped - 88 lines] >> >> Please respond in the newgroup and not by email. -- John Nurick [Microsoft Access MVP] Please respond in the newgroup and not by email. > John, > I have tried linking and importing. I have even tried writing a program > using the earliest version (that I have) of DAO, RDO and ADO. None seem to > work... I always get the same error...unrecognized file format. > This has to be a database file of some sorts as I see section that identify > COLUMNS and rows of data. My only concern is that if I extract the ASCII > data while viewing the BINARY of the file...I might miss something of > importance to my customer. > I don't have access to the source code or the code-slinger that did the old > program. So that is not an option either. > The earliest version of Access that I have is 95,,,and that too fires the > error mentioned above. I am at a loss I guess and while I hate to admit > defeat...I think I have to here. The customer will not be too happy with > having to re-key the data. > Thanks again for your help. If you can think of anything that might be > help...please let me know. > Jack C. Brinegar > Innovative Software > jcbrinegar@iss-c.com Access 95 and later were Windows applications. If you are sure that the original was DOS then it might be a Access1 database. I believe that this cannot be converted by any current Access version and needs a converter tool (available from MS web site?). I seem to remember a thread a few months ago so it might be worth googling on this news group. Peter  SignaturePeter Gillett : peter.gillett@ukgateway.net Totnes : South Devon If the data if fixed length (open up the file with a editor), then you likely can import the data. You might want to rename the file extension (on a copy of course!!). Ms-access can actually import fixed length data files, and MOST (if not all) old style data files are fixed length fields and fixed length records. For a customer file, and some of the data, importing might not be that hard. Further, are there any "reports" that allow you to send the output to a text file? Often, it far better to write some code that parses and imports report data then trying to read the original. So, are there any reports that could be used to suck the data out of? (assuming you send the output to a text file..and not a printer). If the softwar does not have a print to file option, then just setup a "text" printer in windows, and use the "print to file" option... And, poke around, as often many programs had/have some "export" option which will export the data to some text format for you... SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal All, Just want to know who will be versed at the safty tech.???? Forti123 > If the data if fixed length (open up the file with a editor), then you > likely can import the data. [quoted text clipped - 16 lines] > And, poke around, as often many programs had/have some "export" option which > will export the data to some text format for you... |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.