With all this talk about subvalues, and how they might mess up reporting,
I'm wondering: How many users have completely (for all but the most trivial
reports) abandoned using Access/English etc.?

Until recently, I worked for a software company using Universe which writes
ALL reports in BASIC, with selecting being mostly internal and sometimes
external (SSELECT...). This gives them added control to suspend/resume/log
these reports and they _never_ produce them any other way.

I know small companies usually rely on the built-in tools for reports, but
larger ones sometimes give over to more capable (and more expensive)
programming solutions.

Is this common? I'm curious about only those who don't use Access/English
etc.

Thanks much!

Ed

Hey Ed,

We use Access for simple lists, edit reports, and registers. And of course
we use Access for selecting data. But the majority of our reports are
written in Basic.

There are a number of GUI based and browser based report writers on the
market. Realistically they are only as good as the data dictionaries of the
software package. Most end users do not know how to create dict's. The
slickest report writer does nothing if the dict's are crap.

Jeff

"Ed Sheehan" <NOedsSPAM (AT) xmission (DOT) com> wrote

I think we qualify as a smaller company but we use an inhouse web reporting
framework for our reports since 1998.

-Bob

"Ed Sheehan" <NOedsSPAM (AT) xmission (DOT) com> wrote

Interesting question. I came from a company that designed all of their
reports using Access. This allowed us to create a report generation
program that created Access statements for our customers giving them
custom reports very easily.

We took advantage of being able to create some complicated dictionary
items with F correlatives and later called Basic programs which made
our reporting capabilities very flexible.

The new company I work for now does no reporting with Access. All of
their application reports are done using Basic. This results in no
user definable reports causing IT to get involved in every reporting
change/need.

My experience in using F correlatives and knowing how to manipulate
Access for maximum output has allowed me to produce one time requests
for information for our users with some surprise at how fast I was able
to get it to them. They were used to waiting for a new program to be
written to retrieve the information they requested.

Now, all this being said, writing Basic reports does allow the maximum
flexibility of formatting reports and the user is not limited to the
typical columner format. Sometimes useful reports need to be in a
non-typical format. It also allows us to easily insert codes with
these reports and fax/email them using ActiveFax.

I still use Access for one off reports and data analysis. I hope to
one day write a report generator tool for this company that creates
Access reports that all users can use.

Cliff

Ed Sheehan wrote:
I suspect the question is not "who doesn't use the mv query language
for reporting" but "who doesn't use the mv query language for the
entire report". I haven't seen any shops that don't use select lists
or execute any selects at all. If your basic program uses the query
language

I did have developers come to me in the early 90's with a proposal to
do reports only in basic and I convinced them otherwise, recognizing
that there would be times when we wanted to improve the performance and
take the hit of maintaining the basic code instead of the mv query
code. The ability to deploy the query language to end-users and also
use student employees to maintain reports (and write I-descs) was just
too valuable for our organization at that time.

Cheers! --dawn

I'm with Cliff on this. On the systems I've designed myself, I've
built beautiful dictionary items, with good looking headings.. not the
ugly "PO.NO.........." stuff from out of the box.

Most of my reports are just a shell around an ACCESS statement. I get
the dates, parameters in BASIC, then form a sentence with headings and
footers and EXECUTE it.

Of course, there are always BASIC reports to write, but a well designed
system can do most things using the DATA retrieval language.

Douglas



Cliff wrote:

On Wed, 5 Apr 2006 17:44:12 -0600, "Ed Sheehan"
<NOedsSPAM (AT) xmission (DOT) com> wrote:

Here I go again... <sorry>

Over the years I had become accustomed to relying less and less on
R83/AP Access and writing specific programs for specific customer
reporting functions. We developed "skeleton" programs and procedures
(sub-totalling, totalling, etc) that were re-used, over and over. We
maintained this through a conversion AP/Pro -> UV, in the mid-90's,
particularly as we maintained the "Pick" flavour. We never really
got into RetrieVe (UVQuery?? UniQuery??) and all the nice things it,
and UV dictionaries, offered over R83/AP

With our conversion UV -> OpenQM in 2004, I had a close look at
QMQuery - closer, then, to RetrieVe than Pick's Access, together with
D- and I-type dictionary items, and found that just about all of our
"standard" reporting could be easily converted to QMQuery, the worst
examples only requiring "reformatting". And no more bloody
corellatives; corellatives probably being the main reason we got into
the habit of writing programs for reports in the first place
......."Just get in there and write it. Don't bother stuffing around
testing corellatives to see if you can get them to work..."

I-types with subroutine calls allowed us to have maximum flexibility
for a minimum number of subroutines. I realize that AP/D3's CALL
probably gives this functionality, but at the time, t'was in its
infancy.

PROCs weren't supported either, then, under OpenQM, so if I had to do
"something" about SELECTs, SSELECTs, etc, I thought I may as well
write programs, building sentences which were then EXECUTEd. One
side-benefit of this is that we now have the capability of displaying
the report (QMQuery's PAN and SCROLL permit this) and then allowing
the operator to print the report, if required, simply by re-EXECUTING
the sentence with a LPTR added.... Users seem to think this is a
"giant step forward" and if the capability is missing from a report
they want, they start the usual "customer demand process".

I must stress, however, that AP/Pro's Access (as I left it) and
RetrieVe (as I left it) both lacked features and functions that are
available, now, with QMQuery and if I was without QMQuery, I'd
probably still be writing programs for reports as opposed to writing
programs with QMQuery sentences embedded..... unless I'd gone off into
retirement, fishing... which was, and still is, a serious
consideration

What are these things that're in QMQuery? Thing like multiple
page-throws for multiple break-points, CSV, CALC, EVAL, FMT, COL.HDG,
PAN, SCROLL, PERC, AVG, MAX, MIN, etc, etc. I appreciate that some of
these things are in UV, and alternatives might be in D3, but we just
never had the need to get "a round tuit". The "new" things like
REPORT.STYLE, PCL, OVERLAY, BOXED, just add greatly to the benefits.

One other thing comes to mind, here, too, and that is the advent of
laser printers which allowed us a 180 character line length (A4,
landscape, 16cpi, 8 lpi) which means we're not forever chasing the
last elusive character from dictionary width specifications.... and
QMQuery's FMT and COL.HDG come in handy, here, too. No more
multiple dictionary items to get the output result for which we're
looking...

</ad>, not that I ever really started...
Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....

Doesn't the ACCESS vs BASIC debate reflect the essential cultural
differences between IT and users. The IT department always wants to
centralise and take control away from the end user to make them
dependent. PICK and ACCESS allows the end-user to bypass the IT
priesthood and to produce the results they want when they want them.
Not in some indefinite timescale in the future.

Look back at the late '70s/early '80s and learn from the reaction of
traditional IT to products like Lotus and dBase which moved power down
to the user.

When I was at a London college (around '85), the main student system
went over to Cognos. Any changes to the structure of the database could
only be made once a year when the whole system was taken off line.

We needed a simple staff system for planning & modelling. After months
of getting nowhere with IT, I developed one in a couple of days (plus
he rest of the week entering the data) using Creator on a GA box. They
were incandescent!!. But it gave us (in Planning & Statistics) the data
and reports that we needed.

If a company goes the BASIC route, it is moving aways from the
essentially user-oriented PICK system back to IT.

I feel that this is one of the factors that has worked against PICK
overe the years.

Alan Pritchard

In article <e11koc$69n$1 (AT) news (DOT) xmission.com>, NOedsSPAM (AT) xmission (DOT) com (Ed
Sheehan) wrote:


Best wishes
Alan Pritchard MPhil FCLIP MBCS
The GLOBAL GAZETTEER™: the world on file
http://www.allm-geodata.com
Tel: +44 (0) 1202 417 477

Please reply to: alan.pritchard (AT) gmail (DOT) com

Hi
I use BASIC for the complicated reports in conjunction with a SSELECT.
However I encourage users to remember that they can get excellent results
with the query language and often give them quick and easy searches. One
that springs to mind is - we have sent the statements out and Mrs Smith says
she has paid but it is not on her account. A quick LIST RECEIPTS WITH
RECVALUE "200.00" AND WITH RECDATE "1-4-06" soon finds it without a great
paper hunt. Or LIST INVOICES WITH STATUS NE "P" soon catches drivers
hanging on to difficult deliveries in their cab. Of course I encourage the
users to ask us how preferably by email as it keeps us in touch over things
that are not an issue - I believe it is called CRM without the cost or
aggro.
Peter McMurray
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote