Looking for the SQL behind a Lawson report

Unfortunately, the backend of a Lawson program is COBOL, not SQL. If you can read COBOL, then this will be easy. If you can't, take a look at the AP Technical Text for AP265. This will get you started as it lists the tables referenced in the code. Beyond that, you are looking at reverse engineering the COBOL code.

You could have your dba run a trace on your session while you run the AP265 app. It will capture all the SQL statements that you are generating. You could also use Toad or Oracle OEM to capture the SQL.

I have the AP technical text and will also give the trace option a try.

Thanks for the info.

The AP265 is the payment register report and I built it using 4 tables which are APPAYMENT, APINVOICE, APVENMAST and CBBANKINST. The Payment status which is a derived field in Lawson will need to built in crystal since this is not a field in the database.

Interesting idea Tom. I'll have to give that a try myself.

Chris,

We do this all the time. It's how we figured out Lawson Applications didn't work with their Time Managment application that they where selling and we bought (4 years ago). We saw that Lawson was looking for five blanks in a field and Time Management was looking for one blank, so the intergration would never work. We had to tell Lawson how to fix their procedures and triggers in Time Management to work with Lawson, they put our patch as one of their releases.

Tom