Comparing Fields within the Same Record with SELECT
ddspell-m3
same record, but when I do, I get an error, specifically: [4] syntax
error
My statement is:
SELECT WO WITH QTY.COMP < WO.QTY
WO.QTY is the work order quantity which is the quantity to produce
QTY.COMP is the quantity completed
I want the select to do the work of giving me a list of work orders
that have not been completed by comparing the quantity completed to
the work order quantity.
I'm thinking that the select will be more efficient than just getting
a list of work orders and having a program read each record and do the
compare, right??
Thanks,
Danny
Ed Sheehan
the input statement. You can do a correlative though. Let's call it
WO.NOT.COMPL:
001 A
002 99
003 WOs Not]Completed
004
005
006
007 MD0,
008 A;N(WO.QTY) - N(QTY.COMP)
009 R
010 9
Then do:
SELECT WO WITH WO.NOT.COMPL > "0"
Ed
"ddspell-m3" <dds...@gmail.com> wrote in message
news:e51306b9-0ee9-4b96...@y38g2000hsy.googlegroups.com...
Tony Gravagno
SELECT. See:
removepleaseNebula-RnD.com/blog/tech/mv/2008/03/d3shell1.html
(Not completely apparent how that applies, sorry, but it's a start.)
Yeah I know, people are going to crawl out of the woodwork to insist
it should all be native, documented, supported, and presented on a
golden platter. *GD&R* While they've been grumbling for the last
decade about what "should" be the rest of us are using the tools as
they "are", and as they were designed, and moving on to other things.
You can have this in a few minutes Danny, just not exactly the way you
expect it.
T
Chandru Murthi
message news:1mo3645uiq17umrmq...@4ax.com...
> Fairly easily accomplished with shell variables or an overload on
> SELECT. See:
> removepleaseNebula-RnD.com/blog/tech/mv/2008/03/d3shell1.html
> (Not completely apparent how that applies, sorry, but it's a start.)
>
> Yeah I know, people are going to crawl out of the woodwork to insist
> it should all be native, documented, supported, and presented on a
> golden platter. *GD&R* While they've been grumbling for the last
> decade about what "should" be the rest of us are using the tools as
> they "are", and as they were designed, and moving on to other things.
Yeah, I'll crawl out and tell you that these points occur to me:
1-Dict solution is simple, obvious, clear and takes about 20 SECONDS. Bad
example to choose.
2-Appropos of previous discussions on platform independence, touting a
D3-only solution for something so trivial is counter-productive.
3-And pointing to a website which you yourself say is not apparently
applicable is...what? Do you have a SIMPLER solution? If so, post it.
Chandru
"All this has happened before and will happen again"
Frank Winans
> I'm using D3 and I'm trying to do a compare of two fields within the
> same record, but when I do, I get an error, specifically: [4] syntax
> error
>
in a sort/list, but must write a dict to accomplish that? If not, shouldn't it be?
I mean, this verges on being a "Frequently Asked Question" here.
I cannot think they'd omit such a factoid due to Marketing's embarrassment,
as none of the competition can do this feature, and the constraint lets the
SORT/LIST verbs run at very high speeds even on gruelling chores.
Tony Gravagno
>2-Appropos of previous discussions on platform independence, touting a
>D3-only solution for something so trivial is counter-productive.
He's running D3 and not likely to move away. The decision to use a
more complex solution in the name of cross-platform portability is up
to the end-user.
>3-And pointing to a website which you yourself say is not apparently
>applicable is...what? Do you have a SIMPLER solution? If so, post it.
>
>Chandru
We've already discussed solutions like this in the past, always for
free. These days I give occasional freebies, free referals to my
prior free solutions, and if people don't want those they can pay for
my time and/or fingers.
T
Mark Brown
news:YeOdneMMiZlY-__V...@posted.internetamerica...
R83 did not allow ADI to ADI comparison, so why restart the obvious.
SQL allows field to field compares, as do almost all of the later mv
implementers because they are not constrained by 40 years of expediency and
near sightedness.
--
Mark
Frank Winans
> "Frank Winans" wrote
> > Is it noted in the d3 docs that you cannot directly compare two attributes
> > in a sort/list, but must write a dict to accomplish that? If not,
> > shouldn't it be?
> >
> > I mean, this verges on being a "Frequently Asked Question" here.
> > I cannot think they'd omit such a factoid due to Marketing's
> > and the constraint lets the SORT/LIST verbs run at very high speeds
> > even on gruelling chores.
>
> R83 did not allow ADI to ADI comparison, so why restart the obvious.
>
> SQL allows field to field compares, as do almost all of the later mv
> implementers because they are not constrained by 40 years of
> expediency and near sightedness.
>
>
Thanks, I didn't know that other mv providers could do that.
I've got reservations about omitting things from user
guides just because they are widely known to R83 users. Don'tcha
wanna sell mv stuff to people _not_ on the AARP membership rolls, too?
I'm not even sure all the R83 users ever knew this constraint, either.
Ross Ferris
To paraphrase TG, "it is all available, but may not be for free"
I think I have mentioned pre-processors in the past (I don't THINK I
would have missed an opportunity NOT to go on and on about the
benefits of "Snippet Technology" with Visage :-)
Anyway, the same/similar approach can be plugged in & adapted here -
simply copy the existing/original(?) verbs you want to intercept to
another name (eg: LIST becomes &LIST, SSELECT --> &SELECT). Your
program can now parse the command line looking for YOUR new special
syntax .... lets use, say, EVAL( ... )
Now "all" you need to do is :
* interpret what is between the brackets & write a subroutine, and
write a temporary dictionary out. If it was me, the presence of
boolean test symbols ( = # <= >= < > [maybe EQ NE LE GE LT GT]) would
result in a True/False response, whereas operators like + - / * would
give a "numeric" result
*modify the parsed command line to reference your "new" dictionaries,
AND refer to the "original"/real (eg: &LIST) command
* EXECUTE "your" modified statement
* decatalog your subroutines & delete dict items
The "tricky" bit may come about when you are interpreting dict items,
but if you aren't into writing your own "A" & "F" correlative
handlers, or handling complex dictionary items (eg: containing a CALL
statement), then remember that your subroutine could always execute a
&LIST and CAPTURE the values .... maybe
Anyway, this might point someone in what I think is the "right"
direction
Tony Gravagno
routine that I have already created as a sample solution to this
problem. (Curiosity got to me and I wanted to make sure this was as
easy as I thought.) I'll post it on our freeware page for download in
a few days - I want to do some testing on it first and I do have a lot
of other. As with any open source project, contributions are welcome
to improve the code for what has been called a FAQ.
Also as Ross notes, there are caveats to the approach. Two dict items
will compare in different ways depending on whether they use
conversions, correlatives, or both. The first stab at this isn't
going to address these subtleties.
T
Tony Gravagno
just posted to our freeware page: Comparative.AQL.txt. You can ctrl-c
the page, then ctrl-v it into your favorite editor. See
remove.pleaseNebula-RnD.com/freeware
Note that D3 doesn't require quotes around fields, so given the
statement below:
SELECT WO WITH QTY.COMP < WO.QTY
D3 wouldn't know if that meant field WO.QTY or the literal "WO.QTY".
For this reason the comparative.aql currently requires you to catalog
new verbs like CSELECT and CSORT, all of which point to the same
program, so the above becomes:
CSELECT WO WITH QTY.COMP < WO.QTY
See the code comments for all documentation.
This is a good place to mention that another open source freeware item
is available on the same page, NebulaDecatalog.txt. This makes sure
that if you say:
DECATALOG BP
That any catalog entries removed from the MD actually do point to the
BP file. This program should simply substitute for the default
DECATALOG verb. Instructions are in the code.
Please post bug reports and enhancement requests to the Nebula R&D
forum:
remove.pleaseNebula-RnD.com/forum
HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
ddspell-m3
I learned about MV on Pr1me INFORMATION back in the late eighties and
I could have sworn that I could have compared two fields in the same
select statement. Anway, I've been in D3 now for over 7 years, and
while I've adapted, I'm not total comfortable with it. INFORMATION,
and later with uniVerse, my life was easier. Who knows, maybe I was
using I-descriptors.
Oh well... thanks again.
-- Danny
Brian Speirs
(UniVerse, OpenQM etc) do have a direct field to field comparison.
Cheers,
Brian
ddspell-m3
wrote:
Thanks for confirming. It has been a long time since I worked in
uniVerse. I really miss using INFORMATION. It was my first MVDB and it
was so easy to use compared to the unforgiving Pick/D3.
Tony Gravagno
>I really miss using INFORMATION. It was my first MVDB and it
>was so easy to use compared to the unforgiving Pick/D3.
I feel the same way about working with Universe and especially
Unidata. They're the most unforgiving MV environments in the market
with syntax and casing.
It's ridiculous that some commands need to be cased alternatively
between upper and lower, otherwise the systm simply doesn't process
it.
Look, Mr UniComputer: when I say NAME, Name, or name, _you_ know that
there is an item in the dict or voc with that ID, oops, @ID, and I
should not have to spell it out exactly for you each time - and
differently depending on where we are at the moment.
And also, Mr UniComputer, if I say LIKE ...foo... or [this] or
"[that]", you should know damned well what I'm talking about without
me having to tell you what flavor you are. There is little chance in
hell that I'm going to be looking for the literal "..." or "[z]".
The point is that computers were meant to serve us, not the other way
around. It's absolutely infuriating that the following conditions
exist:
1) We are all enslaved by rigid syntax that was defined 30 years ago.
2) Most people in this market seem to like it like that.
3) The current crop of MV engineers somehow think this is the way it
should be. Compare this to how the rest of the world is light years
ahead with speech recognition, bayesian-based learning algorithms, and
other methods that continue to divorce "syntax" from "function".
So that's just my opinion about U2 syntax anyway. There are many
other areas where I feel D3 is much more versatile and forgiving - and
there are things that are available in U2 that I wish we had in D3.
For the best of both worlds I've come to appreciate QM, Caché, and I
was quite impressed with my small exposure to Reality in this area as
well.
YMMV of course.
T
Chandru Murthi
Chandru
"Tony Gravagno" <address.i...@removethis.com.invalid> wrote in
message news:7o4u64tkjdfndtat1...@4ax.com...