In some situation for Pro2 users, we need to implement tracking and storage in the target database of all changes of the records. In the use of Pro2 based on replication triggers, this is possible, in terms of Pro2, this is called Audit Database &...

For some cases needs that on the target schema table name presents suffix and prefix and full table name in upper case. For example: on the Source database the table has name "сustomer". on the Target database the table name should be...

Updating the Pro2 table definitions subsequent to schema changes is really painful. In a recent case we had to individually re-map every field individually (A few hundred of them) because the full table remap would not work.

Hard to see the value of maintaining temp-tables to show statistics at the end of each pass about records skipped - especially if the above suggestion is implemented to periodically "restart" each queue. In any event - we often shuffle queue...

The logging (ie "repllog") would be useful if it included the date/time when the original queue record was triggered. That would permit analysis. As it is we only know when the record got replicated - but we have no idea how long it waited before...

The processing of each thread should re-start at the beginning every 5 or 10 minutes. Some of our threads get so busy that they don't reach the end for 5 hours (sometimes much more). The result is that records skipped because they are locked or embraced...

Would like the ability to run a command against an OpenEdge database and be able to identify when it is being replicated via Pro2. Example: proutil dbname -C describe Currently shows other features enabled for a database. I realize we do not have...

It would be nice to have an installer instead of a zip-archive: The installer would include: All required Pro2 files Based on Pro2SQL / Pro2Oracle / Pro2Pro some configuration settings OpenEdge installation included (maybe even a 'bundle'...

We are currently looking for a way in which we can update the source database independently of the Replication database. We have successfully been able to architect our solution in a way that would prevent data loss without having to rely on bulk loading...

This is something that we ran across that would be a beneficial feature. Instead of having to shutdown the process on the SQL side or modify the ReplTableXref procqrec, you could instead flip the flag on the ReplDBXref procqrec field to false and be able...