n_x_l
n_x_l

Reputation: 1610

Order by creation time in OpenEdge

Is there an automatic way of knowing which rows are the latest to have been added to an OpenEdge table? I am working with a client and have access to their database, but they are not saving ids nor timestamps for the data.

I was wondering if, hopefully, OpenEdge is somehow doing this out of the box. (I doubt it is but it won't hurt to check)

Edit: My Goal

My goal from this is to be able to only import the new data, i.e. the delta, of a specific table. Without having which rows are new, I am forced to import everything because I have no clue what was aded.

Upvotes: 1

Views: 612

Answers (2)

Tom Bascom
Tom Bascom

Reputation: 14020

You could use database triggers to meet this need. In order to do so you will need to be able to write and deploy trigger procedures. And you need to keep in mind that the 4GL and SQL-92 engines do not recognize each other's triggers. So if updates are possible via SQL, 4GL triggers will be blind to those updates. And vice-versa. (If you do not use SQL none of this matters.)

You would probably want to use WRITE triggers to catch both insertions and updates to data. Do you care about deletes?

Simple-minded 4gl WRITE trigger:

TRIGGER PROCEDURE FOR WRITE OF Customer. /* OLD BUFFER oldCustomer. */  /* OLD BUFFER is optional and not needed in this use case ... */

  output to "customer.dat" append.

  export customer.

  output close.

  return.

end.

Upvotes: 1

Tim Kuehn
Tim Kuehn

Reputation: 3251

1) Short answer is No - there's no "in the box" way for you to tell which records were added, or the order they were added.

The only way to tell the order of creation is by applying a sequence or by time-stamping the record. Since your application does neither, you're out of luck.

2) If you're looking for changes w/out applying schema changes, you can capture changes using session or db triggers to capture updates to the db, and saving that activity log somewhere.

3) If you're just looking for a "delta" - you can take a periodic backup of the database, and then use queries to compare the current db with the backup db and get the differences that way.

4) Maintain a db on the customer site with the contents of the last table dump. The next time you want to get deltas from the customer, compare that table's contents with the current table, dump the differences, then update the db table to match the current db's table.

5) Personally. I'd talk to the customer and see if (a) they actually require this functionality, (b) find out what they think about adding some fields and a bit of code to the system to get an activity log. Adding a few fields and some code to update them shouldn't be that big of a deal.

Upvotes: 1

Related Questions