A few years ago, before migrating from Triton 3.1a to Baan 5c, we did a standard dump from the Triton system. We kept the Triton system alive in a read-only mode, just so users could access archive data.

Recently the Triton system died. While I'm sure we could spend thousands of dollars building a new Unix system, load the app and data... you all know the drill... we though that we could somehow load the data into another database and get the data we need. In reality, the user's only care about sales orders, so the task doesn't seem that daunting.

Now the question. Does anyone know where (when, how... etc.) we can get documentation on the data format of the dump files? Any information would be helpful.

Thank you in advance.

RR

Hi Rick,

I assume that you dumped the tables into one large file.
Within this file for each table there should be a section declaring all domains, then the data should follow.
Do you have a backup of the data dictionary too?
Even if you don't, it shouldn't be too difficult to create data ready to be loaded into let's say mysql DB.
Depending on the backups you have I think it might be less work to recreate the original Baan system though.
Do you have a support contract still? If yes (and your backup includes $BSE, not only the dump file), I would suggest to get a licence for linux and recreate the system on a small server.
Will be happy to lend a hand in either way.

Regards

Norbert

Thanks for the info.

Let me bring you up to speed on my three issues...

(1) We actually did three sets of dumps, due to the file sizes. Each set contains two files, one with a list of table names and the row count for each table, and the other is the dump itself.

The dumps are:
Tables GEx to TDx
Tables TFx
Tables TGx to TUx

Once again, we moved to Baan 5c... this is just archive data!

(2) What brought this to the forefront was our raid unit died. If we can get it up again, we could reload the backups and put it back online. At this point in time, we really haven't even diagnosed the raid, so I don't know if it is repairable. We are trying to keep the costs down (archive data... you know.)

(3) My intention, was to load just the tables the users need (purchase order history) into MySQL or SQL Server, and set our report writer up to pull the information. That way they never have to even go into Triton.

So... what are my options?

Thanks again

RR

I have not seen a tool outside Baan that could read the Baan dumps. Was the Baan app on the same raid set? If so, I think you better try to get that raid set back in the air or look for backup files of trton and restore these on a server.

Hope this helps,
Dick

The app is not on the same raid set... only the data. We might be able to get it back up, but...

The dump file is all plain text, and appears to be in a standard format. I was hoping we could write some code to parse it into another database format.

RR

Hi Rick,

I think that I fully understand your intention.
From the users point of view, he only wants to see 'simple' history date for instance old sales or purchase orders.
Although I don't know triton data base logic, I am quite sure that a lot of this 'simple' data is living in referenced tables.
Of course you can gather all this data and create some condensed tables in mysql or similar, but this requieres some work to identify the data structure.
I just had a look at a bigdump. As I already guessed, the data is described by domains - and the information about the domains is not contained in the dump itself. You will need the DD if you don't want to spend a lot of time guessing the data format and dependencies.
If you have a look at such a dump and the DD on your live Baan 5 system, you will see how these informations are structured ... the task you have in mind is not too hard indeed, but it requieres some thinking though :-)

regards

Norbert

So, you still have the triton app, and you have some dumps. In that case I suggest:

1. first restore your db on what ever drive. Even if you link it via the network is fine.
2. check what tables you want to convert to e.g. mySQL
3. make a dump of these tables that have a seperator or with fixed width. bdbpre -x or -t
4. Now you need to find a tool that can upload these dumps in your database. MSQL has such tools for itself, I have no idea what whould be the best for MySQL.

Hope this helps,
Dick

Ok... then I think we don't have much choice but to get the old system up and running first. Let's call this thread closed... and once we get the system back up, I'll drop another post.

Thanks again to all that responded!

RR