*.DB file won't import into Access 1

[wekkew]

Hello

Ok, it's years (and years) since I used Paradox so bear with me. I have an app which stores data in a number of .DB and .PX files.

Question One - what's the difference between .DB and .PX?

Question Two - as we don't have Paradox (yes I know...) I've tried importing these tables into Access97, some .DB come in ok, but for others I get "External table isn't in the expected format". I've also tried to examine the tables via VB and some report back as containing no fields!

All I want to do is to understand the structure of the tables so I can create some custom reports, prob using VB/ADO

Any help much appreciated

Thanks
Kate

 

[Guest_imported]

First:
.DB is the table itself
.PX is an index file (primary/composite key)
.VAL is the validation file (e.g. sets required fields, etc)
.XGx and .YGx are secondary indices
.TV controls how the table view appears in Paradox.

Reasons for Access not importing the tables include :
- Paradox format is newer than formats supported by the Access version.
- Paradox table contains data formats not supported in Access, e.g. Blob fields, Formatted Memo.

Even when import to Access is successful, the data types in Access may end up different to those in the Paradox table - this will depend on the data, e.g. what may have been a small integer field in Paradox may end up as a long integer field type in Access, the size of alpha fields can be different, etc.

HTH

 

[wekkew]

Thank you - very useful

Kate

 

[PhilUK]

Paradox uses various Sort Orders, eg ASCII or International (or other languages). It is unlikely that your tables from a single source have mixed indexes, but it could be.

When I've had problems loading Pdox into Access, the settings in Local Machine/Software/Microsoft/Jet/Engines/Paradox are worth checking, also perhaps the Jet/ISAM Formats.

Hope this helps

Phil

 

[bx1423]

I have gotten this import to work before. You need to export the data from the *.db file as a dbase file. I used dBASEIV as my format. Worked like a charm. But do watch out for the fields with larger data in them.

Good luck.

MP

 

[p1m3]

I have found this works for me. If you have Quattro-Pro export the .DB file into the spreadsheet then import or copy QPro data into Excel and from there into access. Excel accepts most of the Qpo-Data straight across.
P1M3

 

[Guest_imported]

Since you did not mention other extensions (such as
.XGx, .YGx, and .TV). There is some chance that you are talking about Paradox 4.5 for DOS (it uses *.db, *.px, *.val, etc., but it does not use .XGx, .YGx, or .TV). I have the 4.5 for DOS, 5 and 7 versions of Paradox, and the versions 2, 97 and 2000 of MS Access, and could tell you the structures that your tables have. If you do not mind sending me the tables (db with its px files) by mail on a diskette or CD (or e-mail if small) I could export them for you or give you the structures, etc. If you send me the whole application I could see what it does and tell you. I have a CD burner. I am a Data Systems Analyst and deal with confidential information on a daily basis.

I can be reached at:

http://www.keen.com/cesarinternational

I am in Reseda, California, U.S.A.

César

 

[waynemelrose]

I have inherited a large number of Paradox 3.5 databases that I want to access but don't have a copy of Pdox 3.5 or a computer that would run it if I could get it. I have been offered a copy of Paradox 7. Can I read those old files with that? Any other suggestions please?

Wayne Melrose

 

[syrena]

Wayne,
I have imported Paradox 3.5 databases into Paradox 7 in the past, without any problems.
Of course, all forms and reports will have to be rebuilt.

Syrena

 

[ck1999]

I am trying to acces a .db file with MS access and am getting an error about the format. I am using Access 2003 and have Microsoft jet 4.0 latest version installed. Does anyone have any ideas.

Chris

 

[TonyMcGuire]

Does anyone have any ideas."

Use a real database system?


Errors from Access are often due to the ODBC driver - the M$ driver isn't very good, and many report success with alternate driver. That is, IF you use ODBC to access the table.

Another issue, I think, is that the M$ driver requires a single key on the first field only.

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[kentsteve2005]

This one is an interesting question, one that I have had trouble with several times, thank you Wekkew.