Dat File Database Format??
B-Dog
trying to convert to dotnet. I'd like to be able to import the data into an
access database but I don't know which format the dat files are in. Here is
the first few lines of the dat file. If anyone could help me figure out
which type this is it would be greatly appreciated.
ÿÿÿÿ ®
öf¨"ó Mr John Smithh Parkside Jewelers
1776 Parkside Blvd. San Diego CA 92001 Radio
619-555-8837 619-555-8113
´Former Name: Discount Jewelers
Jüÿÿ ò
u¨" GY$Ov¨" X N
2344 Parkside Jewelers P.O. Box 33847 San
Diego, CA 92003
ûn"!ò Manager Save-At Drug Store
758 Some Street Los Angeles CA 90049
´(sample customer)
PO Box 345 Brentwood Ca 90049
uu¨"ô Frank Jones bABC Company
123 Washington St San Diego CA 92111
619-444-1234 619-523-4321
Ítá$ Jennifer Kaszemi
Atascocita Place Drive Humble TX 77346
281-234-4328
Âv¨"ö Joe's Garage
11052 El Camino Real Oceanside
-wá$ Paul Gilbert 44 Good
Stree 44 Good Street
Bay St. Louis MS 39520 601-444-6323
¤sá$ Wand Wandas Rodgers JWAR Information Services
3453 F.M. 1960 ByPass #7 Humble TX 77338
281-444-1339
óvá$ Stan & Erle Stadnicking
44 Good Street
Bay Shadow MS 39520 621-237-6323
oyð$| Luis Gonzalez
Atascocita Lakeway Humble TX 72246
221-322-3773
Õ
XuÄ$û
Norbert Munkel
thank you for crossposting to so many groups. This always helps. And big
thank you for posting the file itself. :-(
from http://filext.com:
---snip---
Can be just about anything: text, graphic, or general binary data. There
is no specific structure for a .DAT file. You can use an editor like
EditPad Pro to look inside a .DAT file and possible determine its
contents and relationship with a program.
---snap---
Norbert
B-Dog
many groups. Thanks
"Norbert Munkel" <n...@acoreus.de> wrote in message
news:C8y4e.23$P2....@se2-cb104-9.zrh1.ch.colt.net...
Jurgen Haan
> I have an old dos program that uses dat files to store the data and I'm
> trying to convert to dotnet. I'd like to be able to import the data into an
> access database but I don't know which format the dat files are in. Here is
> the first few lines of the dat file. If anyone could help me figure out
> which type this is it would be greatly appreciated.
This is most probably a custom format.
The only way to decompile this format is to aquire the format from the
programmer who created the dos program.
If you're interested in the ascii content from the file you should try
dragging the file through the program strings under Linux.
I don't know of any windows equivalent of strings (apart from cygwin).
-R-
Jan M. Nelken
> If you're interested in the ascii content from the file you should try
> dragging the file through the program strings under Linux.
> I don't know of any windows equivalent of strings (apart from cygwin).
strings.exe available from www.sysinternals.com - this site has a lot of very
good and interesting goodies for Bill Gates followers.
Jan M. Nelken
Lemming
>I have an old dos program that uses dat files to store the data and I'm
>trying to convert to dotnet. I'd like to be able to import the data into an
>access database but I don't know which format the dat files are in. Here is
>the first few lines of the dat file. If anyone could help me figure out
>which type this is it would be greatly appreciated.
[snip file contents]
Is the old DOS program a home-grown one, or an off the shelf package?
If home-grown do you have access to the source code? If it's a
package, you could try searching on http://www.wotsit.org although
there is only one ".dat" type file listed, for DataFlex:
http://www.wotsit.org/search.asp?s=database.
Failing all that, reverse engineering the file ought to be possible,
judging from the chunk you posted. Try using a hex editor rather than
trying to view the file as plain text.
Do you think this file contains only a single record type, or are all
record types for the application held in this file? Are there any
files of other types, e.g. indexes or other control files?
The likelihood is there will be a header block, containing information
such as file version, length of file, possibly pointers to the first
data record and the first deleted record and "other stuff" which you
may or may not be able to work out the function. After that I'd
expect to see the records. The binary embedded in the records
themselves are either numeric fields, or control information. If the
former, then it should be reasonably trivial to work out the record
length and go from there. if the latter then you likely have variable
length records, and so you should expect to see a record header block
containing the overall record length, plus field headers for the
variable length fields. It will be quite time-consuming, but it ought
to be possible.
If you still have the original application, you could compare what it
shows you on screen with what is in the file and use that as a clue to
the file contents. Alternatively, ow many records are there? If
there aren't too many it might be quicker/simpler just to copy the
data from the old application to the new one by hand.
Lemming
--
Curiosity *may* have killed Schrodinger's cat.