The big issue with any replication is the volume of data. If it's a small table then replicating the whole table every day isn't going to be an issue, but what if it grows? In a previous job we were dumping around 100GB of data every night because of a solution that started dumping 10GB a night and the data grew. We eventually got to a point where it didn't finish dumping the data before the next dump kicked off. Not pleasant.
In short, a flat rip of data is the simplest solution but it could get expensive in terms of time.
A better approach would just be to replicate the data that's changed. For this there are 2 options: triggers (but you have to be careful because any SQL clients connected don't fire ABL triggers), or implement a way of seeing what's changed. Progress have released a new feature in 11.7 called Change Data Capture that you can use for this, but that would require an upgrade for you.
On the subject on upgrades, you need to be thinking about this now. 10.2B will be retired at some point. Version 12 has now been announced, which means 10.2B will become unsupported at some stage around this release. There's no official date for this yet, but Progress only actively support the last 2 major versions.