Create trigger & recids

Margot Hoekstra

New Member
Hi!

Maybe somebody has a better idea or has a suggestion how to do the following:

I have two progress systems running. 1 is from an external vendor (in this example called 1), the other is ours (in this example called 2). We need to update database 2 with all the data which is used in a table used by the system 1 on a daily base. We only allowed to change the create trigger on that table in system 1. The table in system 1 will never be updated or deleted.

When a record is created in system 1 and i have only access to the create trigger, the only thing i have is the recid. So, i want to write the recid in the other database and when every user is ready with system 1, read the records i need to load in system 2 with the recid and after processing delete the entry where the recid is stored.

This will be a daily process because the table is very big in system 1 and i need all the records created on that day.

Is there anybody who has a better suggestion or has a suggestion how to store the recid in database 2 (as recid, as character or as decimal)?

Thanks!
 

bertnaik

New Member
I would not choose the recid (or the newer rowid for that matter) for such a purpose. If the database 1 is deleted and reloaded with data, there is a good chance all the recids will be different from the original ones.
Why don't you create the entire record - or at least the index field values in database 2?
 
Have you considered using RAW-TRANSFER? The example below is from Progress documentation.

TRIGGER PROCEDURE FOR REPLICATION-CREATE OF Customer.
CREATE Replication-Log.
ASSIGN
Replication-Log.Taskid = DBTASKID(LDBNAME(BUFFER Replication-Log))
Replication-Log.Table = 'Customer'
Replication-Log.Action = 'CREATE'.
RAW-TRANSFER Customer TO Replication-Log.Record.
 
If the schema changes for the table you're using, you will not be able to use RAW-TRANSFER.

E.g.
CREATE rawTable.
RAW-TRANSFER customer to rawTable.rawField.

DB Change to customer.

CREATE customer.
RAW-TRANSFER rawTable.rawField to customer. ***FAILS***

Using RAW would only be a good method, if (like ROWID and RECID) the life-span of the raw information is brief.

If you need to identify the record, store the primary index key value(s).


Jon
 

Margot Hoekstra

New Member
Of course it is better to copy the index-fields instead of recid or rowid. But this is in this case not possible. The create trigger is triggering directly after the create statement. So, the index-fields are all empty!
The only thing i have at that moment is a recid or rowid.
When a dump & load is necessary for system 1, we have to make sure that every record is copied in system 2.

Other ideas? Or does anybody have a suggestion how to store the recid (as integer, character etc)?
 

jongpau

Member
Maybe a silly question but... why are you only allowed to modify the CREATE trigger and not the WRITE trigger? That would give you the index fields you require. Also, if I remember well (someone correct me if I am wrong please), ROWID is not reliable until the record is written to the database because it can change after index fields are changed. The same goes for the value of RECID with an Oracle database.

Also, if memory serves me well, you cannot connect databases in a database trigger (this may have been changed by now, I never tried again after I found out in version 8-something) so will database 2 always be connected in the application that runs on database 1, or connected by the procedure(s) that create records in the table in question?

You can store the recid in a field with the RECID datatype in database 2 (assuming you will be creating a table for this). But as said by someone else, the value of RECID is highly inreliable when dumping and loading the database (and most probably it is impossible to find back the correct record when database 1 has been dumped and loaded before you start copying the records).
 

Margot Hoekstra

New Member
It is not a silly question. But because system 1 is made by another company i am not allowed to use another trigger than the create one (commercial reason :awink: ). On the other hand, i only want this 'recid' once, so if the encrypted source has more than one assigns and/or updates the write trigger will be runned more than once.
(after updating the second system i delete the record with the recids).

Good point of that thing with connecting a database in a database trigger. I'll test that.

I also was assuming that storing a rowid is not very safe.... Recids has their problems too though.....

Does anybody know if storing the recid as an character is better than storing it as an integer???? Someone over here said he red something about that. I cannot find something back in the documentation.

thx to everybody who is replying and thinking about it!
 
Top