SEO

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

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
>

Thanks for the response, I'll be looking into this.