I just posted the first in a series where I will compare features of
the Pick query language, which I decided to refer to as GIRLS, with
SQL. I chose just one of a number of features and plan to do a few
more blogs with such comparisons.

See http://www.tincat-group.com/mewsings

Along with the above ad, I do have a question. If you want to LIST an
attribute value from an attribute in a file other than the one in your
LIST statement, what are the options for syntax in the dictionary and
the LIST statement?

LIST MY_FILE MY_FILE_ATTRIBUTE THAT_OTHER_FILE_ATTRIBUTE

For example, in UniQuery, you add an I-desc named
THAT_OTHER_FILE_ATTRIBUTE with a TRANS using a value from MY_FILE as a
foreign key to THAT_OTHER_FILE.

In D3, I think you use a TFILE (in an F correlative, or something like
that) and suspect I can find the exact syntax for that.

Are there other ways to do this in various flavors of the Pick Query
language?

Thanks. --dawn

Hi Dawn,

In keeping with the USENET way, I haven't read your article yet but:

This does not answer your question, I will leave that to Chandru or one
of the other gurus but if I may offer a suggestion: The concept of
dictionaries is something that IMHO is a key factor in the superiority
of the MV's over SQL and similar query systems. This is a huge part of
the ability to create more ... ehrm, elegant? queries.

Long after this was a standard part of the GIRLS family (to use your
phrase), the relational folks began to jury-rigged the idea of "views"
into their systems. The dictionary approach gives much more flexibility
and power and I think is easier to comprehend and use. Oh, that's sort
of what MV is about, isn't it? <g>
-Tom

Tom deL wrote:
Agreed. My next entry will talk about one aspect of this. Some
features are
1) It is an extensible descriptive (rather than prescriptive) schema
2) You can create synonyms, or describe data with different
"conversions"
3) It is a vocabulary for the user wanting to ask about this 1 entity
4) You can change a field from describing stored data to derived data
without changing queries. You can change a field from single to
multi-valued or vice-versa without breaking queries.

The draft of my next blog entry (not this one) makes an analogy to Mary
Poppin's carpet bag from which you can pull out things that clearly
didn't fit in a narrowly-defined container. If anyone has any other or
better analogies, I'm all ears.

Yup. Cheers! --dawn

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

If the only route to data were programmatic and through a dict and if
the existence of a cataloged program that refers to a dict somehow
constrained changes to the item in some reasonable and logical fashion then
the "referential integrity" complaint would not exist. But the ability to
define a dict entry that may not be true - an index on a translation for
instance - and the ability to assault ANY file, including dicts, with the
editor are just two of many worm holes that make GIRLS a very dangerous
system to use. It is absolutely amazing how many very good applications
exist despite these traps. The catalog of such worm holes - a qualified
select statement that says nnn items selected but does not say "of yyy items
in the file" for instance - would be interesting reading. What I'm really
trying to say is simply that our superior system is only superior in the
eyes of the programmer or his boss and only because the missing constraints
make it possible to produce programs very fast and therefore very cheap.
But use those programs at your own risk because it is doubtful that anyone
could ever prove that they are doing no harm. The customers that I have
served over the years have been willing to accept these risks because they
got the results fast and cheap - and without obvious problems. The
competitors - Timberline comes to mind - had elaborate safety methods
combined with high prices and slow implementations.
"The king is Dead - Long Live the King" if we could just identify him.

BobJ

dawn wrote:
Compare features, or come up with highly contrived examples to show SQL
in the worst light possible?

Your self admission of being "rusty" when it comes to SQL hardly makes
your blog entry an informed one.

No, I'm not going to submit a design for a SQL pizza management system.

Many of your posts follow the same pattern. "Hey all. What do you
think of this?" There's never really seems to be any point to your
information gathering. It does not appear that you are working on a
project or have any specific problem to solve.

I guess I just don't "get it".

The sheer volume of the posting you do in this and other newsgroups
leads me to believe that perhaps you have a little too much free time
on your hands.

--
Kevin Powick

dawn wrote:

Meaning that there may be missing or no dict items at all, leaving the
developer in a virtual minefield when choosing new attribute numbers to
add data.

That can present the data inaccurately and leave one wondering which of
the 20 synonyms for an attribute is the "correct" one.

So the results could change and the user is left wondering how/why?

Not likely true if your sort criteria is based on a single value field
that you change to multi-valued.

Outside of creating columnar, printed reports that few people use these
days, GIRLS, Access, English, AQL, etc. seems to have very few, if any
real, advantages over SQL.

I would say one of the biggest disadvantages of AQL is the inabilty to
return a data set. You may have a wonderful set of dicts in a customer
file that has all sorts of neat translations and conversions, but when
it comes to using that information in a PICK BASIC program, the best
AQL can do for you is get you a set of keys. You must then write all
the code to access the various files to retrieve, display and/or update
that information

Also, outside of using the Pick EDitor, and UPdate processor - neither
of which should be unleased on the common end-user, the only way to
update information in MV files is via BASIC programs. The data
manipulation features of SQL are quite handy and certainly more
powerful than those available in AQL/GIRLS.

Note that I'm not advocating SQL over MV, I use both. I just tire of
the smugness I sometimes see among MV advocates who think MV is above
and beyond all else. MV has its share of warts too.

--
Kevin Powick

BobJ wrote:

True. In the wrong hands, these systems become nightmares because they
pretty well let you do whatever you want. While some claim power and
flexibility, one can end up paying the real price of lost data
integrity.

More of a testimate to the developers than the platform.

While true, I think the only programs that "Pick" can produce very
fast/cheap today are the traditional "green screen". Outside of that,
you become just as encumbered with development, deployment, and support
issues as any other developer

--
Kevin Powick

Kevin Powick wrote:
I'm current on the Relational Model, even if I'm not currently coding
SQL. No one I know keeps completely current on every front. I tend to
be well-read in some areas, but I will admit to ignorance on many, many
fronts. I don't think it would be fair to characterize my blogs as
uninformed, would it?

I'm not requesting it.

I'll have to think about that. I always pick a single point to present
in each blog, with supporting information around that point. It sounds
like either I am not making that point clear or for some other reason
you are not hearing it. If you look at the title and the last
paragraph of each blog, you should at least have a good hint at the
point.

I'm curious if others have this problem. Am I too obscure? Do I
wander too far from the point? Hmmmm. I will try to see if I can do
better for you, Kevin.

The project I am working on is one to help the industry move beyond
such things as First Normal Form and three-valued logic. The broader
project is to find and promote those approaches, techniques, and tools
that help provide a big bang for the buck in quality software
development. I'm trying to take what I have learned in my career to
date and help make a difference in the area of software development,
even if only in my own little way.

Bummer. Was there anything in this week's entry that did not make
logical sense?

Another possibility might be that the use of these newsgroups is a part
of my project work or business plan, both for learning and
participating.

Thanks for reading. If you have any more specifics on what would make
it a better read, feel free to tell me here or drop me an e-mail.
Cheers! --dawn

And what is the point of this?

Kevin Powick wrote:
It got me to thinking. Access is more specialized that SQL. Some have
suggested the Access does not allow update or insert and this is a
weakness. After thinking for it a while I would have to disagree.
Access is a *data extraction* tool. Where it had features to update
the database (DELETE,COPY) is can be a problem. This is the reason
many systems have a faux-Access without these verbs, which are
really TCL Verbs and not part of access.

Patrick, <;=)

P.S. Kevin, try not to scare the new posters.

they're just rumors