Multiple REVIEW Repository to store History Data

, , ,
1

Current our REVIEW implementation uses only 1 review repository. All reports which write historical data use this one reporsitory.

WE are getting ready to build a REVIEW report which we anticipates will write out a significant amount of historical data.

We would like to create a second REVIEW Repository to store the historical data generated by this complex report.

We have tested the concept by:

  1. Unload the existing REVIEW repository
  2. Reload back to Adabas with a new file number
  3. Refresh the new REVIEW Repository
  4. Edit the complex REVIEW Report, go to options and change the history target fnr to the new file number.
  5. Started the report
  6. Clone the DDM REVIEW-ADABAS-V451-CLOG
  7. Change the file number of the new ddm
  8. Write natural program against the new ddm and see that all captured historical data is indeed there.

The concept seems to work, i.e. having the complex report writes history data to a history file that is different from all the other reports that are active and collecting historical data. The question is that is this a supported implementation by SAG? Will we run into issue with future REVIEW upgrades, etc

Many thanks.

2

Just curious as you don’t sound as if this is meant to be a flip-flop,
what happens when you want to “archive” the 2nd set of report
data, are you going to have “n” historical copies ?

3

Hi,

This is an interesting approach. What is the problem you are trying to solve.
Is it to create a report that collects all data you need and run your own reports on that data?
If so, I would like to ask you to open a change enhancement.

Currently, you can use your method but we may change the way how we collect and store data.

Thank you,
Wolfgang

4

Hi!

Thanks for the response. The main reason we want to start with a separate History file for the complex report is because this history file we need to expose to the application developers. Given their requirements to have the ability to delete records out of the history file, we DBA much prefer to isolate their processing from our core history file where all of our other historical data is stored. These other historical data is mission-critical to us DBA hence should not be tempered with.

I just want to understand where SAG stands with regards to this design. And you share it.

Thank you very much.

Min