How to back up Server new table to local db

[slh]

Dear All,

If 1 person within the team did changes to the Server LIVe database schema (Eg: new table, new field), what is the best recommended practise to update the changes locally?

 

[MaximMonin]

dump table structure and load to another db.
Or connect to both and create increament delta.df file.

 

[slh]

Hi Maxim,

Thanks a lot for replying. I tried to use Data Administration to export Table Apple from database A as *.df file.

When I connect to database B to load Table: Apple it prompted me that the tables , fields exists already!

 

[slh]

Maxim,

1.Verify my steps for dumping, Connect to database A: Data Administration> Admin> Dump Data and Definitions> Data Definitions (*.df file)

2.For Loading, Connect to database B: Data Administration> Admin> Load Data and Definitions> Data Definitions (*.df file)> Input file (Search for the filename and dorectory save)> Ok

3.Result: Error during ADD FIELD YEAR **, FIELD already exists with name YEAR

 

[rzr]

that is because you are trynig to load the full table contents again to your local Db when the schema already exists . If you want to load only the *newly* added fields to your local DB, then do the incremental delta as stated above.

Alternatively, since you are loading the *.df to your *local db*, you can when loading the df :
a. Check the option "Output Errors to File
b. Check the option "Commit Even with Errors"

This will load the *new* schema to your local, and all errors will be redirected to file. You can later review the error file.

 

[slh]

Hi Rzr,

Thanks, will go back and try it out, cheers!

 

[slh]

Hi Rzr,

Given a scenerio where a team of our developer concurrently amend the database Table(s)/ Field (s) Locally, what would be the most recommended methods to ensure schema consistencies ?

Regards

 

[rzr]

when you say *local db*, i'm assuming that you mean your development database. What do you want your local db to be consistent with?

When making schema change to LIVE, the normal process would be to
1. Get the schema reviewed and approved by the schema committee team (Consists of Sr. Programmers / Architects / DBA' etc)
2. Load the Schema to Dev db - review and verify the your application is working correctly
3. Load the Schema to Test db - let users review and verify the your application is working correctly and take sign-off
4. Load the Schema to LIVE.

 

[slh]

Hi RZR,

The issues here is development db resides locally,
Scenerio 1 : 2 or 3 developers might be making change to similar table/field (eg:add/delete)
Scenerio 2 : developer might be making change to within their source codes that might use tables/fields from the other party.

 

[rzr]

I'm sorry, I may have lost you here... what is that you want to achieve/implement/do?

 

[slh]

Hi rzr,

Thanks for the fast response all this while.

1.The sequence of updates should there be multiple developer make changes that will effect the other party tables/ codes.

2.Your recommended practises to increamentally update the table schema is fine while there exists 1 developer, how's it gonna be when there is multiple developer making changes to the db schema concurrently ?

 

[RealHeavyDude]

Multiple developers changing the database schema simultaneously is not good practice. Every database change must pass a quality toll gate and there should be a fixed schedule and responsibility as to when and by whom changes to the database schema in the central development database should be applied.

Don't get mad at me, but what you describe is something I have seen in so many different Progress development shops - and it almost always lead to the same result: Inconsistent and bad database design.

You should design a process that holds water in the first place and then implement it - not the other way 'round.

Just my 2 cents.

Heavy Regards, RealHeavyDude.

 

[TomBascom]

Dear All,

If 1 person within the team did changes to the Server LIVe database schema (Eg: new table, new field), what is the best recommended practise to update the changes locally?

First you change all of the passwords on the production server.

Second you fire the ninny that made changes in production first.

Third you have a meeting with the remaining members of the team and explain the concept of "change control"...