I'm afraid that I've not really used English/Access (apart from (s)SELECTS
in data-basic executes) for a a number of years. Al our reports are
written in data-basic.

As we migrate to a gui front end this is changing into a framework which
generates a dataset from each data-structure (a data structure may represent
one file but they are logically connected) - this is then manipulated in a
standard Windows (dotnet) form to produce the report required.

I have a framework (that I've not yet actually implemented in production)
which extends ACCESS/ENGLISH so that it is more "usable" - this includes
creating "sql-like" joins between files dynamically and the ability to
return an xml dataset rather than a printed report (so it can be used more
effectively in gui presentation). I will put this into our production
code eventually (the biggest hurdle is actually writing the "new"
dictionaries - it relies on a a custom data-schema which is an entry in the
DICT which is then "compiled" to real dictionaries).

Regards
Simon

--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011

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

There have been two or three very important flaws in the capabilities of the
various report writing things supplied by the vendors. The vital ones,
IMHO:
Complete headings are impossible.
Percentages on total lines are difficult.
Control over page breaks is poor. That is, it is difficult to look
ahead to see if the current page has enough lines remaining to start and
finish the level of control break required.
There are others that are important but not show stoppers.
The bottom line is that the capability out of the box is great for quick and
simple reports but not so good for the stuff where presentation is perhaps
more important than content. Everybody assumes that the numbers are
correct so it is presentation that makes the difference when you are trying
to sell something. And that's almost always.
BobJ

"Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote

Every application system I personally worked on used Access as its basis for
reports. Only a few reports utilized BASIC. Of course, this was in the
character days. I saw absolutely no reason for the average report to have to
have a BASIC program. As others have pointed out, the turnaround time for a
report was a tenth or less than writing a new program.

In other's applications, the majority of lists that I have seen could have
been easily (and I stress easily, I don't mean by writing humongous
correlatives) written using Access. Therefore I must conclude a) that Access
has a steep learning curve (unlikely) b) that programmers don't like doing
things in a simple way (possibly) with maybe an element of job security
there.

And for a ridiculous example, a company I unfortunately worked for in 2001
(successful, mind you) had a Report writer front-end written in BASIC, about
3000 lines, which eventually wound up writing a bog-simple Access statement
to generate the list. Of course, they could quote 40 hrs at $150/hr to
modify a report by just deleting a column. So it worked for them, tho' maybe
not for their ignorant clients (who were lawyers...hmm...is there a joke
there?)

Nowadays the climate has changed. with the requirements of pretty display.
However, I can still give you a relevant example: in the browser tool I work
on, there's a standard Listing function, mostly used to display keys and
data for selection from forms. There is, obviously, a sizable chunk of BASIC
code to convert the list to html, but the list itself is generated by a
EXECUTE LIST capturing the output and converting to html. It allows the
developers (programmers though they be) much flexibility in defining Dict
words which then instantly show up on the Listing.

Chandru Murthi

<alan.pritchard (AT) gmail (DOT) com> wrote

Simon Verona wrote:
I'm guessing that mathematically it is more of a link or path for
navigating on a graph (web) of data than a sql-like set-based join,
right? I like how OpenQM does that, by the way. It was described in
an earlier thread.

Very good.

OK, I'm curious -- what, more precisely, are you doing with the custom
schema and dicts? --dawn

Ed Sheehan wrote:
We execute SSELECT statements from BASIC to produce a list of Item-IDs,
often with one or more BY-EXP clauses, then READNEXT ID,VMC in a BASIC
program to produce reports/charts/spreadsheets.

I will SORT from the command prompt, to get a peek at raw data, but the
application never does.

--
frosty

I use access from D3. I use them a lot. But with a little difference. I
do not use it from TCL. I do not use it from BASIC. I do not use it
from D3. I use it from EXCEl or WORD, better, i use it from MS-QUERY.

EXCEL:
There are a some tricks you must know. First, in atribute 3 of the dict
there MUST NOT BE any space. Second, all the numbers MUST be unmasked.
Then, when you have them on Excel, it believes there are text. Nothing
work with formats, etc. You must multiply them by 1 and then copy-paste
values. Very easy. For dates, pass them in internal format and add in a
dict the number 24837. Then change the format on excel to DATE.

Now you have all the excel tools with an AQL sentence. Pivot Tables,
Chars, etc.

WORD:
Same with atribute 3 of the dict. But then if you want f.i to send a
letter to all customers in california your data source is an AQL
sentence, and the variable data you can use are the dicts you have
include in the AQL. Fantastic and very easy.

It works in D3 with the ODBC server running. I do not know in others.

So not, AQL is not death, it is FANTASTIC, for ANY WINDOWS program that
can send and SQL SENTENCE to the data source.

Hope this help

joseba

I designed the schema with the theory of doing "named field" databinding in
my windows application - which meant that I had to have a quick to read (ie
one record) view of my file layout. It simply is a list of the field
names, the attributes that they are stored in, whether any MV are involved,
and if so which other fields are linked.. In addition a data type (numeric,
currency, string, date, time etc) is stored. Lastly, links to other files
are stored as well...

Whilst I've not yet done the named databinding (mainly cos I haven't had
time to write the data schema), I have written a data-reporting engine as
described using this. Dictionaries are generated on the fly as needed to
generate reports, and the reports themselves can return the data in many
forms.

I wanted to also build a series of functions in databasic that did
read/write and dynamic array processing that verified the data against the
schema, but again, I've not had time..

Regards
Simon
--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote