by malcolm >> Thu, 22 Aug 2002 23:35:12 GMT
Hi All,
Following recent private correspondence, I have decided to share my current methodology when it comes to using the Jade Report Writer - the RW. Using consolidated release 220 or later is a MUST.
It is important to understand how the RW has been designed. This is my interpretation of what happens. A typical query will:
1.. Run from a top-level layer, the Report tool UI (or your app) - someone hits the Run button!
2.. Then call an API layer (e.g. the ReportManager class) that you use to submit the report together with selection criteria etc.
3.. The RW uses the report design and specific criteria to builds a SQL-like query using its own JADE method-type language (putting trace flags on will let you see the query - see below).
4.. This in turn is passed to the Query engine (contained in a DLL called JADEAQE.DLL) which in turn does the clever stuff with the JADE Object Manager kernel.
5.. The query engine builds the result set which is passed back to the RW. 6.. The RW builds the presentation of the report for printing or exports the data to file etc. with the results set.
Hope that's reasonably clear. I am open to correction. So, when problems are experienced, the trick is to go looking at what all of the layers have been up to, especially when you receive an unexpected "nothing to report" message. What happens is that things can go wrong, say, within the Query engine and these are not passed back to the higher-level RW in a way that allows a meaningful message to be given to the user.
To mitigate this, especially when developing, the first thing is to turn on the old and new report flags (some of the below might be redundant - not sure). So, put these into the jade.ini file that you are using.
[JadeReportWriter]
LogQuery=true
PassBackException=true
QueryDataFailureTraceOn=true
QueryExecTraceOn=true
QueryPrepTraceOn=true
QueryStatisticsTraceOn=true
QueryConcurrencyTraceOn=false
QueryReadFailureOptionOff=false
Here's my methodology while developing and testing each report:
1.. From the configuration tool, design or modify the view that your report uses.
2.. Open or re-open report (to force a view re-load) - there are sometimes issues with the "current" view (a caching problem?) so I always ensure that I have forced a view reload.
3.. Run the report, either from the Report tool or from your application wrapper.
4.. Examine the jadereportwriter*.log in RW logs folder for any messages / exceptions. You will see the query that has been built on your behalf, which is instructive in itself. Look out for messages from the Query engine layer. The statistics about how many objects have been read etc might help you decide if your query design is up to scratch too (e.g. performance, efficiency etc.).
5.. Examine the RW logs folder for new jrw_dump_* files. These are output when an exception occurs.
Hope that helps you track down this and future problems. It will certainly help you to provide useful information to JADE Support when and if the time comes.
Words of warning:
Don't forget that any reporting tool contains a generic query engine that does its best with the information it has to decide how best to deliver the results you want. If you have particularly complex requirements you may be better off writing the report you want in code within your app.
It is probably also not advisable at this stage to let your end-users fiddle with your carefully crafted reports, other than maybe to re-arrange fields on the page or change the title text etc. You really have to know what you are doing with the RW. This issue is not unique to JADE - how many of us have had to deal with our beloved customers stuffing up Access, Crystal or PowerBuilder reports?
Good luck to all,
Malcolm McCulloch
Unify Ltd