You would need to use triggers to do this. Either database triggers, or
session triggers.

I seem to remember database triggers changed the CRC of the database so
compiled r-code won't work and will need re-compiling. If you don't have
source code (and I doubt you do if you're looking to do this type of
project) than you may need to use session triggers.

I'm not familiar with WDSII, so I can't tell you if you can do session
triggers either. I once had some luck writing session triggers in a wrapper
program that ran the real program. If I recall, it was a PO receiving
program. I had a session trigger to log writes to the po file. I also sent
these to a custom table, so when the user was done, I could get a receiving
log to print.

The program was something like:

on write of poitem do:
run pologger.
end.
run vendor-supplied-po-receiving-program.r



<jeremygiberson@gmail.com> wrote in message
news:1138372566.661711.3610@o13g2000cwo.googlegrou ps.com...
> Hello all,
>
> Background:
> I am pretty new to progress, as I just started working with it when
> hired on to my current job position. The company I work for is based on
> the WDSII program, and the employees use a terminal emulater to run
> wdsii applications from their desks. My job involves deloping an
> intranet with tools that can accomplish most of the tasks available
> from the wdsii terminal program. We've been using ODBC to interact with
> progress through the SQL-92 interface (progress v9).
>
> Question:
> Most of the web applications that involve mostly read only access to
> information in progress have completed and we are moving on to
> applications that involve writing to the database - and handling very
> important data. I was wondering if there is some kind of report
> available that displays records/tables most recently altered since a
> given date. The idea is to perform a specific task (on the test
> database which has most recent backup version of production) via the
> current wdsii application and analyze what changed in the database.
> Afterwards, when testing the web applications run the same report to
> insure the same result occurs.
>
> Considering the importance of the data being handled I want to take as
> much precaution to changing it as I can. Especially knowing that a
> critical error in field data might not even be noticable untill well
> after the fact. For instance, updating a part record and neglecting to
> update a not so obvious related field in some header table that might
> screw up general ledging, etc.
>
> I figured I'd ask if there was a tool already available, or any one
> knew of some resource that could tell me this specific information
> (since there wasn't a programmers manual in our current wdsii manuals).
> If there is no such tool available I'll probably resort to an
> incredibly slow and time consuming "SELECT *" from all the tables in
> the system and write a script to compare the resulting output.
>
>
> Thanks in advance,
> Jeremy Giberson
>