Re: Reporting tools
- From: Bruce Nichol <reverse_ecurb@xxxxxxxxxxxxxx>
- Date: Tue, 07 Feb 2006 17:33:39 +1100
On 6 Feb 2006 19:25:07 -0800, "dawn" <dawnwolthuis@xxxxxxxxx> wrote:
Bruce Nichol wrote:
On 6 Feb 2006 18:39:09 -0800, "dawn" <dawnwolthuis@xxxxxxxxx> wrote:
A few years back I took a look at reporting tool options for U2. I'm
thinking of doing that again, possibly broadening the scope to all MV
platforms. I can think of mvQuery, Entrinsik Informer, MITS, Sierra
Bravo, and Visage' (is the reporting tool ever licensed separately?).
What else is out there for U2? What do people use with jBASE,
Revelation, D3? Are there any such tools that work with OpenQM?
Thanks for any help getting an initial list. If you would be willing
to chat with me by phone or e-mail about what you know about any of
these products, let me know that too.
And, while you're at it, could you also explain (briefly and without
worrying about pro/con on-going never-ending arguments - at least from
me) why you chose to write/implement/use such a reporting
Just to be clear, are you asking folks why they woud choose any such
tool rather than either writing their own similar tool or using only
the mv query language for end-user reporting? Would this be along the
same lines as asking why anyone ever buys software?
Not at all. I'm not *that* devious. I'm just curious about the
reasons behind MV reporting tools. Their use and their raison d'etre.
For me, gone are the days of "ad hoc" reporting. I've never been
exposed to "native to MV" reporting tools, per se - always done 'em
"longhand". We've just come out the other side of a rewrite of our
application to QM.... We rid ourselves of dozens of PROCS, built
sentences into programs and execute them... Used a bit of 20/20
hindsight halfway through and went back and re-wrote (most of) the
earlier converts.... did away with all the A-type DICT items from
yesterday (I- and D-types only now), Found out more about FMT, EVAL
and all that sort of stuff to rid ourselves of countless DICT
<Aside> We're now making vast use of Martin's PAN and SCROLL for
screen-based reports, as well as, more latterly, his PCL and OVERLAY
for hard-copy reports. Customers seem to be pretty happy with the
"new" hard-copy reports - page borders, heading borders, boxes
wherever they're "wanted".....round-cornered borders and boxes, at
that.... Can't wait until we foist our new "coloured" screen
reports on 'em
Our customers come forward occasionally with a "new" report request. I
suppose I've done hundreds of 'em over the years.... I can't recall a
customer telling me of his "own" report any time in the past (quite a)
few years.... Tend not to promote "do your own reports" too heavily.
That's *our* job... We need the money. *They* need to run their own
business to pay for us to enhance things... <grin>
Perhaps we've got a "perfect" solution (Ho Ho), but "reports" don't
seem to rise above the horizon these days....
I was wondering if today's approach of "front end/back end database"
processing brings the need for "MV native reporting tools" or,
alternatively, the need for "middleware" to fit into (ugh!) SQL and
its ..... children (Crystal Reports, et al) The "front end/back
end" style tends not to be part of our customers' concerns, either
..... at the moment....
I'm just a little confused, so please give more hints about your
interests. thanks. --dawn
You want to know "what". I thought I'd like to know "why" - just to
try to get a handle on what might be coming at me.... and what I might
look to doing about it all.....
If I ever pull my head out of the sand.....
Talon Computer Services
ALBURY NSW Australia
If it ain't broke, fix it until it is....
- Re: Reporting tools
- From: None
- Re: Reporting tools