.D Files? Progress DB files? How to open it?

riestra

New Member
Hi, I've copy the whole directory of an application which contains a lot of .d files, some of them around 90 MB of size.
Are these files Progress tables or files?
How can I import this files to manage the data and migrate it to a MySql DB?
How can I open .D files?
In addition there's .I and .AT files, which I totally don't know what kind of files are or how can I open it...?
Thanks in advance.
 

TomBascom

Curmudgeon
".d" files are dumped data files. They are space delimited quoted text. One record per line. One file per table unless the table size exceeds 2GB -- in which case they may be split up and a number will be appended to the .d -- i.e. .d2. (it depends on which version of Progress dumped them, newer versions are not 2GB limited.)

".i" files are "include" files. They contain snippets of code.

I have no idea what a ".at" file is. take a look at it with Notepad -- maybe it will mean something.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Plaintext dump (*.d) files should contain one record per line, but they don't have to. It is possible for character fields or raw fields to contain carriage returns, so if you are planning on parsing a .d for some reason, you are not guaranteed that a line is a record.

A .d could possibly contain code. I have seen include books with a .d extension; they contained definitions of forms, temp-tables, shared variables, etc. I don't know if this is a convention used in the wider Progress world. It would be rather strange for a single directory to contain both code and data, but anything is possible.

So when in doubt, open the file (read-only, to be safe!) to see what it is. It should be obvious.

Since you want to migrate a Progress database to MySQL, you need data and schema. Even if these .d files are table dumps, that's not enough to build a new database, and you have no guarantee that these files represent every table and every record in every table. They are useless unless you are loading into a DB with identical schema, and remember that you don't necessarily even know which database they came from. So I would consider these .d files interesting but useless for conversion.

Go into the database (databases?) with the data dictionary or data administration tool (one is command-line, the other is GUI) and dump the data from all of the tables to a new empty directory. Make sure there weren't any dump errors. Dump the data definitions (tables, indexes, sequence definitions) to a .df file in that same directory. Also dump current sequence values, if there were any sequences defined, SQL permissions, if applicable, and _User records, if applicable. Then you will have the data you need to build a new database. The Database Administration manual has a section on dump and loading if you need specifics.

I assume your next step is to rebuild your application, since your native application (the one with the .i, .p, etc. files) won't work with a MySQL back-end.
 
Top