Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Coverting database with .dat in dos to MS Access
- Thread starter YCKK
- Start date
Hi
Do you know what the original application was written in? the .dat extension does not bring to mind any particular DOS database package.
Have you examined (copies) of the .dat files, using for example NotePad, are they simple text files?, if yes you may be able to import them directly into Access. If not, and you still have the original software, perhaps it can export the data in csv of some other common format which Access can read (eg Excel, dbf etc).
However it is very unlikely you will be able to import or automatically convert the functionality eg forms, reports etc
Hope this helps Regards
Ken Reay
Freelance Solutions Developer
Boldon Information Systems Ltd
UK
Do you know what the original application was written in? the .dat extension does not bring to mind any particular DOS database package.
Have you examined (copies) of the .dat files, using for example NotePad, are they simple text files?, if yes you may be able to import them directly into Access. If not, and you still have the original software, perhaps it can export the data in csv of some other common format which Access can read (eg Excel, dbf etc).
However it is very unlikely you will be able to import or automatically convert the functionality eg forms, reports etc
Hope this helps Regards
Ken Reay
Freelance Solutions Developer
Boldon Information Systems Ltd
UK
- Thread starter
- #4
HI
OK, so if you know the 'layout' (ie field length and type) for each table, you can Import it into Access, and create Access tables from it.
I would suspect this is only the beginning of your problems (sorry challenges), Once imported I would check the table structures to ensure they are Normalised, and adjust accordingly, then you can apply relationships and referential integrity. During the latter phase you will almost certainly be faced with inconsistencies in the data which will need to be resolved. Then you have have to write the User Interface and functionality.
As a throwback to MainFrame / Minicomputers / Dos who has now evolved to live in the age of PCs / Networks / windows etc, I have been through several such 'experiences'.
Good Luck Regards
Ken Reay
Freelance Solutions Developer
Boldon Information Systems Ltd
UK
OK, so if you know the 'layout' (ie field length and type) for each table, you can Import it into Access, and create Access tables from it.
I would suspect this is only the beginning of your problems (sorry challenges), Once imported I would check the table structures to ensure they are Normalised, and adjust accordingly, then you can apply relationships and referential integrity. During the latter phase you will almost certainly be faced with inconsistencies in the data which will need to be resolved. Then you have have to write the User Interface and functionality.
As a throwback to MainFrame / Minicomputers / Dos who has now evolved to live in the age of PCs / Networks / windows etc, I have been through several such 'experiences'.
Good Luck Regards
Ken Reay
Freelance Solutions Developer
Boldon Information Systems Ltd
UK
gusbrunston
Programmer
[tt]
Hi:
It might help to know the purpose of the file. Just for example, if it was used to transmit Form 1099 payer/payee records to the IRS at Martinsburg, (and I seem to recall those files might have been named "*.dat"
then there's help available.[/tt]
Gus Brunston![[glasses]](/data/assets/smilies/glasses.gif "[glasses] [glasses]")
An old PICKer, using Access2000.
Hi:
It might help to know the purpose of the file. Just for example, if it was used to transmit Form 1099 payer/payee records to the IRS at Martinsburg, (and I seem to recall those files might have been named "*.dat"
then there's help available.[/tt]Gus Brunston
An old PICKer, using Access2000.
missinglinq
Programmer
Hey!
The .DAT extension may well have been used by a number older programming languages, but I know for a fact it was the "official" data file extension for programs developed in Microsoft's QuickBasic 4.5; QB 4.5 was the code engine that Visual Basic was built around. These programs were DOS based, and both sequential access and random access data files used the .DAT extension. Since the files are in ASCII, they were probably sequential access files, which really does make your job easier. As Ormsk said, they will probably be delimited with a comma, but could use a semicolon, tab or even a space instead. Since you said you haven't an idea as to how to go about converting the file(s), I'll list the steps briefly:
1) First off, Right Click on the file(s) and rename them, replacig the .DAT extension with .TXT (Acess doesn't recognize .DAT as a text file)
2) Go to your menu and chose FILE >> GET EXTERNAL DATA >> IMPORT
3) Below the window open up the FILES of TYPE box and choose "TEXT FILES"
4) Go to directory where the file(s) reside and DOUBLE-CLICK THE FILE TO SELECT
5) At this point Access will try to make an intelligent guess as to whether the file records are delimited or fixed length. Assuming you saw some kind of delimiter when you viewed the file, select this option.
6) Next Access will ask what type of delimiter was used; select the appropriate one
7) It'll ask if you want to import it into a new or existing table; pick new
8) Next you need to step thru the fields one at a time and tell Access what the data type is (i.e. text, long integer, double integer, currency)
9) Access will ask if you want it to assign a Primary Key,or have you assign a primary Key, or No Primary Key. You'll want to pick the "No Primary Key" for now, until you've had a chance to evaluate the data. If you picked a Primary Key at this point and the field was blank in one or more records, Access would refuse to let you choose it. You can go back later and choose a Primary.
10) Next choose a table name, click on "FINISH", and Bob's your uncle (as our British friends would say)
I hope this helps. If you have any questions about the above, post them here. I've got this thread marked to email me if any postings come in.
Linq Adams "It's got to be the going,
not the getting there that's good!"
-Harry Chapin
The .DAT extension may well have been used by a number older programming languages, but I know for a fact it was the "official" data file extension for programs developed in Microsoft's QuickBasic 4.5; QB 4.5 was the code engine that Visual Basic was built around. These programs were DOS based, and both sequential access and random access data files used the .DAT extension. Since the files are in ASCII, they were probably sequential access files, which really does make your job easier. As Ormsk said, they will probably be delimited with a comma, but could use a semicolon, tab or even a space instead. Since you said you haven't an idea as to how to go about converting the file(s), I'll list the steps briefly:
1) First off, Right Click on the file(s) and rename them, replacig the .DAT extension with .TXT (Acess doesn't recognize .DAT as a text file)
2) Go to your menu and chose FILE >> GET EXTERNAL DATA >> IMPORT
3) Below the window open up the FILES of TYPE box and choose "TEXT FILES"
4) Go to directory where the file(s) reside and DOUBLE-CLICK THE FILE TO SELECT
5) At this point Access will try to make an intelligent guess as to whether the file records are delimited or fixed length. Assuming you saw some kind of delimiter when you viewed the file, select this option.
6) Next Access will ask what type of delimiter was used; select the appropriate one
7) It'll ask if you want to import it into a new or existing table; pick new
8) Next you need to step thru the fields one at a time and tell Access what the data type is (i.e. text, long integer, double integer, currency)
9) Access will ask if you want it to assign a Primary Key,or have you assign a primary Key, or No Primary Key. You'll want to pick the "No Primary Key" for now, until you've had a chance to evaluate the data. If you picked a Primary Key at this point and the field was blank in one or more records, Access would refuse to let you choose it. You can go back later and choose a Primary.
10) Next choose a table name, click on "FINISH", and Bob's your uncle (as our British friends would say)
I hope this helps. If you have any questions about the above, post them here. I've got this thread marked to email me if any postings come in.
Linq Adams "It's got to be the going,
not the getting there that's good!"
-Harry Chapin
- Status
Similar threads
- Locked
- Question