Question regarding OE Replication and making changes to Targ

Posted by Mark Davies on 19-Mar-2016 02:12

Hi all,


I have an OpenEdge 10.2B06 database that is replicated. We are using OE Replication PLUS and make use of the replicated database as our reporting database and run a couple of reports via CyberQuery connecting to the replicated DB via ODBC.

We have run into the age-old SQL Field width issue and now I am unsure if I need to run the field width adjustment utility on the target only or should I run it on the source and hope it replicates? Anyone done this before? What are your suggestions?

Thanks in advance

OpenEdge General - Forum

All Replies

Posted by chriskirkham on 19-Mar-2016 09:48

Mark,

You just need to update your source and let Replication take over.  We have this issue now and then as well, as our users have Crystal Reports

Thanks,

Chris

Posted by James Palmer on 20-Mar-2016 02:19

You will be unable to make the change on the target as far as I know. The change should be made on the source and it will replicate. Test it with one field first.

Sent from my Windows Phone

Posted by Brian Bowman on 20-Mar-2016 07:58

James is correct on both accounts.

You cannot change the schema on the target.

Any schema changes you make on the source will get replicated to the target.  This includes SQL width.

One additional note:  this does not apply to structural changes like adding an extent etc.

Brian

Sent from my iPad

Brian Bowman
Product Management
Progress Software
Cell: +1 (603) 801-8259
Office:+1 (781) 280-4708

Posted by Frank de Laat on 21-Mar-2016 07:10

Hi,

What about the new 11.6 feature Autonomous Schema Update?

Will this work when it's enabled on the target database where the queries are executed?

Thanks, Frank

Posted by Brian Bowman on 21-Mar-2016 07:58

It will work but it will not updated the schema.  So the Automatic Schema Update (ASU) feature will not work on the target database because it is a target database.
 
We have been discussing this internally and are leaning towards having the SQL engine write a DDL script that could be manually applied to the source.  The other option of having the target database run DDL automatically on the source is very problematic and wrought with potential problems and pitfalls.
 
I would like to hear your thoughts on this though.
 
Thanks

Brian
 
Brian L. Bowman
 
Senior Principal Product Manager
Progress Software Corporation
14 Oak Park, Bedford, MA, USA 01730
 
Phone: +1 (603) 801-8259
Email: bowman@progress.com
 
 

Posted by ChUIMonster on 21-Mar-2016 08:19

I very much like the idea of having an option to generate DDL instead of immediately applying it.  That would permit a nice opportunity to review it first and even possibly distribute it to multiple parties.

Posted by Frank de Laat on 21-Mar-2016 09:55

Although Tom's idea of having an option to generate DDL is interesting, for this specific case I prefer immediately applying the change. Reason is that the application is accepting any data (most is coming via batch processes) and the SQL queries are quite business critical.

Posted by Dmitri Levin on 22-Mar-2016 13:30

Generating DDL script would be great.

This thread is closed