1. Get rid of all advertisements and get unlimited access to documents by upgrading to Premium Membership. Upgrade to Premium Now and also get a Premium Badge!

Best practice for synchronizing environment data

Discussion in 'SQL PL/SQL' started by Schnitzel, Sep 21, 2018.

  1. Schnitzel

    Schnitzel Active Member

    Likes Received:
    Trophy Points:
    Winnipeg, MB
    I need to be able to synchronize configuration data from a development environment to another Target Environment (e.g., Production, Client Testing, etc.)

    I'd like to have a front-end form (in MS Access) pull up a config record in development and the corresponding record in the Target Env; Target-Env data will not be editable in the form.

    Once the config data has been confirmed as correct in development, I want user to be able to click a button on the form to copy the dev data to the Target Env for that record.

    My first-blush attempt involves creating a view that links the records in the two environments. That view becomes the Record Source for the form. When user clicks the button for updating Target Env, the Dev fields in the view get copied to the Target-Env fields, and the sync is complete.

    If I use this approach, I'll need one view for each Target Env which I want to be able to sync to Dev. Is this the best way? In the form, if user selects a different Target Env from a dropdown, the form would need to change the form's Record Source to a different view.

    Or is there a more dynamic way to deal with multiple Target Environments?

  2. zargon

    zargon Community Moderator Forum Guru

    Likes Received:
    Trophy Points:
    Aurora, CO
    You need to explain what you mean by 'environment'.
  3. krasnoslobodtsev_si

    krasnoslobodtsev_si Forum Genius

    Likes Received:
    Trophy Points:
    Russian Federation
    For an example , to support database environments development, test, you can use "thin clones" or tools (ODI,OGG,...) or manual copy if your db is Oracle(DATA_PUMP), or SCRIPTS...

    Explain, what is your environment,what platforms does it consist of?

    Usually, exported configuration of developed functionality to product systems on installing this script at release/hotfix:

    For example:
    generate script ins/upd of your configuration of table, and installing this script at release/hotfix(..etc) your app.

    In any case, the process must be manifested to make it clear "who and what copies of data of configuration".

    Purely technical, we can use ETL-tools, but it's can this may cause undesirable problems : if anybody change of data into the config table and it's copied to prod.