|
Home > Archive > MS Access data conversion > April 2005 > Unknown Data File Type
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Unknown Data File Type
|
|
| Jack Brinegar 2005-04-06, 8:04 pm |
| 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
| |
| John Nurick 2005-04-06, 8:04 pm |
| 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?
On Wed, 9 Feb 2005 04:01:03 -0800, "Jack Brinegar"
< JackBrinegar@discuss
ions.microsoft.com> wrote:
>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
--
John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
| |
| Jack Brinegar 2005-04-06, 8:04 pm |
| 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
"John Nurick" wrote:
> 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?
>
>
>
>
> On Wed, 9 Feb 2005 04:01:03 -0800, "Jack Brinegar"
> < JackBrinegar@discuss
ions.microsoft.com> wrote:
>
>
> --
> John Nurick [Microsoft Access MVP]
>
> Please respond in the newgroup and not by email.
>
| |
| John Nurick 2005-04-06, 8:04 pm |
| 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.
On Wed, 9 Feb 2005 13:19:07 -0800, "Jack Brinegar"
< JackBrinegar@discuss
ions.microsoft.com> wrote:
[color=darkred]
>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
>
>"John Nurick" wrote:
>
--
John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
| |
| Peter Gillett 2005-04-06, 8:04 pm |
| In article <6A8F7769-6AD8-479F-8143- BC9F2F394C5B@microso
ft.com>,
Jack Brinegar < JackBrinegar@discuss
ions.microsoft.com> wrote:
> 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
> "John Nurick" wrote:
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
--
Peter Gillett : peter.gillett@ukgateway.net
Totnes : South Devon
| |
| Albert D. Kallal 2005-04-06, 8:04 pm |
| 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...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@
msn.com
http://www.members.shaw.ca/AlbertKallal
| |
| forti123 2005-04-28, 3:26 am |
| All,
Just want to know who will be versed at the safty tech.????
Forti123
"Albert D. Kallal" < PleaseNOOOsPAMMkalla
l@msn.com> дÈëÓʼþ
news:ud20c08EFHA.1836@tk2msftngp13.phx.gbl...
> 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...
>
>
> --
> Albert D. Kallal (Access MVP)
> Edmonton, Alberta Canada
> pleaseNOOSpamKallal@
msn.com
> http://www.members.shaw.ca/AlbertKallal
>
>
|
|
|
|
|