How do I get the data into the new extents?

[microedgenh]

I have an existing database with only a Schema Area and a new .st file I have added with several extents in it. Adding the .st file offline was successful and now my found.st has everything needed in it. However, how do I get the .df file to reflect the new extents and what tables I want in each extent (aside from manually changing each table)? Is there a way to do this with tablemov or is it not possible? Thanks, Ann.

 

[TomBascom]

I usually use a script and some proutil tablemove commands against an empty copy of the database to get everything where I want it. Then I dump out a new .df file.

I don't generally use tablemove to actually move the data though -- it's very slow for large tables and requires huge amounts of bi space. It's easier to dump & load.

 

[microedgenh]

Thanks for the reply Tom. Here's a better explanation of what I need to do...

Our customers have .df files with different orders then the .df I am delivering to them in the new version of our software. They also have .st files with only Schema Area but the new .st file I am delivering has several extents, etc. in it. Because of this, I can't just dump the customer .d's and load them into the new db because some data will end up in the wrong place. I have added extents offline so I now have a new .st file for the customer database. I then created an incremental .df from the new database and the customer database. I then loaded the incremental .df into the customer database. However, this did not pick up the new extents. I will then dump the .d's from the customer database and load them into the new database. However, when I dump a .df from the customer database, it does not show the new extents for tables, so I am feeling stuck. Thanks, Ann.

 

[Casper]

I'm sure Tom will jump in, but you are talking about 2 entire different things.
Extents have nothing (directly) to do with df files. Extents are the files which hold data in an area.

If you changed the database structure in the sense you moved tables from one area to another then you have to do a dump load (for the reasons Tom already gave you).

If I change structure I normally dump the df at the clients server, change the df programmatically and load it in a newly created database.
This df file governs the placing of tables/index in areas.
I make sure I have enough extents in each area to hold the data. (These extents you define per area in your st file).

After that I dump the data from the 'old' database and load it in the new one.

So you never find extents in a df file.

Casper

 

[microedgenh]

Thanks Casper. I think I am saying extents instead of Storage Areas because there are storage areas in the .df file and that is what I am reaferring to. Sorry for the confusion. Thanks, Ann.

 

[Casper]

Well,

I think you should do this either Tom's way (dump the df load in into a new database with the area's you need defined in the st file, use table move to move the (empty) tables, dump the data from the old database and load it into the new one )
or
use the method I described previous (dump df, change df, load df in new database with according area's, dunp data old database and load into new database).

Casper.

 

[TomBascom]

Storage areas really aren't any different than extents for this discussion -- they're both invisible to code. Table assignments to storage areas don't impact code.

Why are you concerned about the order that things are found in the df file? That sounds like an r-code consistency concern but that really shouldn't be an issue with a modern release of Progress (which, as I recall, you have) nor should it be an issue for someone who is already supporting a lot of customer systems -- you're either shipping p-code and compiling on-site or you've got the r-code issue under control through other means. Adding storage areas to the mix isn't going to impact that.

 

[Casper]

Storage areas really aren't any different than extents for this discussion -- they're both invisible to code. Table assignments to storage areas don't impact code.

I know but I'm a bit confused with the fact that there was a problem with the extents or with area's (which need a dump/load, which has much more impact IMO)
Furthermore if you make an incremental df to achieve getting different storage area's, I don't know what the result will be....

But maybe I don't understand the problem clearly.

Casper.

 

[Casper]

Although reading this for the scond time I might have an idea what is the problem.

We have some 80 customers and they don't have the same database structure.
Any change in the database is in principle independent of the underlying structure. What we do is that, since we know (or can know) the structure at the client site, we have a set of scripts which update the database to a new version.
Depending on the structre of the database at the customers site the incremental df file is (automagically) edited so it reflexs the database structure at the client side.
After this step the df is applied. This way we never have problems upgrading clients of ours.
It is fairly easy to make a generic method to achieve this.
The fun part is to decide where new tables should be added...

I hope this makes sense (I should be sleeping now)

Casper.