Re: ROWID

heinrich@castor.mai.de (Heinrich Seebauer) writes: >Let me first thank you for posyting this clearing statement. Your Welcome....and no one has yelled yet!!! >The strategy for this kind of replication is to INSERT the row into >the original table, and then to SELECT it back, applying, one after >another, the different replication condition for each of the targets. >If the SELECT succeeds, the row is forwarded to the specified target. >ROWID has been the one and only handle to support this mechanism. Not >all of the tables being replicated have a unique key, not is it >recommended to equip them with such a device. The tables themselves >must not be altered, and the data model must be the same, regardless >replication is running or not. >Surely, the ROWIDs are used inside a single transaction only, thus >preventing them (at least I hope so!) from being changed. >Qs: Could the ROWID field, mentioned above, do the job? Could anyone >imagine a better solution for the problem of INSERT/reFETCH ? The new ROWID data type (for lack of a better word:) could be used. If that would not fall into your criteria for changing the structure of the table. Another possibility/idea/brain cramp would be to use triggers. WARNING: I have not tried to do this. It may be worth a shot. Ron Delpiere-Smith # Standard Disclaimer reds@informix.com