I'm just guessing that Rep Server won't do it for you. A couple of years back I implemented a general purpose update queue and replication capability. It was pretty straightforward and I'm sure it'd be easy for you to do it.
Basically, what you need is a queue (you can populate it by trigger--we were doing all updates through a program so the program took care of it, but triggers would work fine). Then you can create a simple program that reads the queue of updates and propegates them to the secondary server. My inclination would be to implement this in Java using a ResultSet as the generic container.
Your queue would contain:
table_name of the table modified
key value of the row's key (single-column keys obviously make this easier)
key column name (simplifies the program a little)
operation (insert, update, delete)
Your program periodically reads all the rows in the queue and performs the corresponding operation. In the case of INSERTs and UPDATEs, it reads the whole row from the source DB and then performs the operation on the target. In the case of a delete, it just uses the key to create a DELETE statement.
If you'd be interested in communicating directly with me about this problem, it's one I've done a fair amount of work on and I'd be interested if you've come up with a different solution or whatever.
Good luck!
John
nsjmcraig@netscape.net