Can anyone suggest a way of Replicating a group of tables from one
database out to another under these conditions:

+ Source database is version 8.1.7.4
+ Destination database is version is 10.2
+ Tables contain Longs
+ Tables do not have primary keys
+ Changes need to be applied to destination tables asap after the commit.

I've looked at Data Guard, Streams, & Snapshots, non of which fits the
requirement.

Unfortunately upgrading the Source database is not an option for us due
to the application being used.

Currently we are using a software solution that I specifically wrote to
perform the task. But it has been suggested that there are better
Oracle solutions. I am interested in using one of these if possible.

--

Kind regards
David Gempton - IT Consultant

On Aug 3, 7:02*pm, David Gempton <davidg@ttc4it_dot_co_dot_nz> wrote:
The better solutions start with the advent of Oracle 9i and progress
onwards through the newer releases; since you're stuck at 8.1.7.4 for
the source side you're then stuck with the homegrown 'solution'
currently in place as 8.1.7.4 is the last bastion of Oracle Parallel
Server (the precursor to RAC, and unfortunately incompatible with it)
and you have no access to Data Guard or Streams. You do have access
to Standby Server, but I believe that is not compatible with Data
Guard.

I believe you have the best you can get given the Oracle release
(8.1.7.4) you're using.


David Fitzjarrell

On Aug 3, 7:02*pm, David Gempton <davidg@ttc4it_dot_co_dot_nz> wrote:
The better solutions start with the advent of Oracle 9i and progress
onwards through the newer releases; since you're stuck at 8.1.7.4 for
the source side you're then stuck with the homegrown 'solution'
currently in place as 8.1.7.4 is the last bastion of Oracle Parallel
Server (the precursor to RAC, and unfortunately incompatible with it)
and you have no access to Data Guard or Streams. You do have access
to Standby Server, but I believe that is not compatible with Data
Guard.

I believe you have the best you can get given the Oracle release
(8.1.7.4) you're using.


David Fitzjarrell

On Aug 3, 7:02*pm, David Gempton <davidg@ttc4it_dot_co_dot_nz> wrote:
The better solutions start with the advent of Oracle 9i and progress
onwards through the newer releases; since you're stuck at 8.1.7.4 for
the source side you're then stuck with the homegrown 'solution'
currently in place as 8.1.7.4 is the last bastion of Oracle Parallel
Server (the precursor to RAC, and unfortunately incompatible with it)
and you have no access to Data Guard or Streams. You do have access
to Standby Server, but I believe that is not compatible with Data
Guard.

I believe you have the best you can get given the Oracle release
(8.1.7.4) you're using.


David Fitzjarrell

On Aug 3, 7:02*pm, David Gempton <davidg@ttc4it_dot_co_dot_nz> wrote:
The better solutions start with the advent of Oracle 9i and progress
onwards through the newer releases; since you're stuck at 8.1.7.4 for
the source side you're then stuck with the homegrown 'solution'
currently in place as 8.1.7.4 is the last bastion of Oracle Parallel
Server (the precursor to RAC, and unfortunately incompatible with it)
and you have no access to Data Guard or Streams. You do have access
to Standby Server, but I believe that is not compatible with Data
Guard.

I believe you have the best you can get given the Oracle release
(8.1.7.4) you're using.


David Fitzjarrell

fitzjarrell (AT) cox (DOT) net wrote:

Thanks for your prompt reply.

You have confirmed what I suspected.

It's the functionality in 9i that I need but the application vendor has
basically said they want two arms and a leg to move their software.

I think our only practical option will be to continue using our home
grown solution until the vendor eventually moves up to a current version
of the DB.

We're lucky, our solution is reliable and enables us to audit the status
of the remote databases that we are updating. So running with it for a
while longer should be ok.

--

Kind regards
David Gempton

fitzjarrell (AT) cox (DOT) net wrote:

Thanks for your prompt reply.

You have confirmed what I suspected.

It's the functionality in 9i that I need but the application vendor has
basically said they want two arms and a leg to move their software.

I think our only practical option will be to continue using our home
grown solution until the vendor eventually moves up to a current version
of the DB.

We're lucky, our solution is reliable and enables us to audit the status
of the remote databases that we are updating. So running with it for a
while longer should be ok.

--

Kind regards
David Gempton

fitzjarrell (AT) cox (DOT) net wrote:

Thanks for your prompt reply.

You have confirmed what I suspected.

It's the functionality in 9i that I need but the application vendor has
basically said they want two arms and a leg to move their software.

I think our only practical option will be to continue using our home
grown solution until the vendor eventually moves up to a current version
of the DB.

We're lucky, our solution is reliable and enables us to audit the status
of the remote databases that we are updating. So running with it for a
while longer should be ok.

--

Kind regards
David Gempton

fitzjarrell (AT) cox (DOT) net wrote:

Thanks for your prompt reply.

You have confirmed what I suspected.

It's the functionality in 9i that I need but the application vendor has
basically said they want two arms and a leg to move their software.

I think our only practical option will be to continue using our home
grown solution until the vendor eventually moves up to a current version
of the DB.

We're lucky, our solution is reliable and enables us to audit the status
of the remote databases that we are updating. So running with it for a
while longer should be ok.

--

Kind regards
David Gempton