Re: Reports good for reports?

From: Jacqui Caren <Jacqui.Caren_at_ig.co.uk>
Date: 1997/01/03
Message-ID: <E3FxK2.87A_at_ig.co.uk>#1/1


cc to John L Dunn <misioror_at_gas.uug.arizona.edu>

In article comp.databases.oracle.tools:<Pine.SOL.3.91.961231161039.23231A

	-100000_at_helium.gas.uug.arizona.edu>,
	John L Dunn <misioror_at_gas.uug.arizona.edu> writes:

>Greetings:
>
>We're evaluating tools for use mainly in developing reports. We use
>Cognos' Impromptu for end-user queries, but some standard reports are

Have you looked at corvu - contect john bornholt at johnb_at_isluk.co.uk

>just a bit too complicated to produce easily with this tool, so we are
>looking for alternatives. One of the options is Developer/2000 and the
>Reports component.
>
>We want to produce reports with charts to about 350 physicians, along
>with other required reports to administration and other health agencies.
>The "develop once, deploy to either C/S or Web" is intriguing, since
>eventually we'd like to post info on our server, to be picked up if
>needed. In the meantime, we can kill some trees and produce the reports.
>
>Now:
>1. How good is Reports at creating report output?
>2. I've seen postings that it is a buggy product, quirky, etc. Is this true?
>3. How hard is Reports to learn? To master?
>4. What other alternatives should I consider?

<PLUG>
I can suggest our DataPublisher, esp if you require high quality and/or highly computational reports. :-) As a bit of background DataPublisher is based upon the FrameMaker DTP system and embeds reporting and document control functionality. This means that you can convert an example Frame document into a report template by embedding reporting scripts. The template is then "built" and the build produces a report document. It has been used to produce reports over 3000 pages long (each month) and currently produces 50,000 7 page full color reports each with approx eight color graphs and tables over a five days period every month. It is not a point and click tool, but is very very powerful.

As the scripting language is Perl, you get a platform independant programming language with access to the entire CPAN module list :-)

See http://wwwperl.co.uk/ig/dp.html
</PLUG>

>5. How much hot air is the "develop once, deploy wherever" mantra?

I have to say that the Oracle D2000/web option is probably a good way to go if

  1. you are already a sizable oracle customer
  2. you have an investment in oracle technology
  3. you dont mind being tied to oracle. :-)
  4. you can afford the required licences :-)

Most of the tools that I have used would have to be considered early alpha if I did not know they were second or third generation production tools. :-( However, if you are already oracle tool users you will probably find them as an improvement :-)

Dont ignore the licencing issues - oracle have recently hammered many web RDBMS providers by asking for massive licence fees for use of thier web technology via the internet.

Another solution is to use java based solutions. Many exist and while some are very very good, many are rubbish.

We have found that having a system that allows creation of multiple output media formats means that you can satisfy many requirements. i.e. We already produce CSV files for every graph and table in a document. It is possible to embed these CSV files into the report (by reference) and this embedding is reflected when the report is converted into PDF. Currently no Frame to HTML convertor provides hyperlinks for embedded content...

>Any and all biased opinions welcomed! TIA,

If you want to talk contact me via email. We use a lot of different technologies and have evaluated many others for corporate customers.

>John Dunn
>The University Physicians
>520-321-3508

All the best,

        Jacqui Caren

-- 
Jacqui Caren, Software Systems, Paul Ingram Group Ltd. J.Caren_at_ig.co.uk
Commercial perl resources - support,training,products etc
 http://www.perl.co.uk/ - to get an entry - contact www_at_perl.co.uk
AD: Need flexible, high quality reporting? - www.perl.co.uk/ig/dp.html
Received on Fri Jan 03 1997 - 00:00:00 CET

Original text of this message