Hello CDP,

My boss pointed out to me yesterday that putting a date processing code
in the output conversion attr (7) of a dict item caused the selection
criteria on a SELECT to be iconv'd from human format "mm/dd/yy" to
internal PICK format. I was more than a lil surprised by this (to say
the least) and after some digging I find that 'd' date codes and 'm'
mask codes in the output conversion of a dictionary cause an iconv on
the select criteria if that dict is used in the comparison (this is
according to the warning in the definition of selection criteria in the
AP & D3 manuals I use for reference).

I did some more looking on this newsgroup and hear that 't' codes in
the output conversion field of the dict may also cause the selection
criteria to be iconv'd.

So my questions... what other codes used in attr7 of a dict cause an
iconv on selection criteria (besides 'd' and 'm')? Is this true only
in D3 or is the same true in other PICK db's? I tried using a called
BASIC sub in attr7 which worked when LIST'ing (did its output
conversion) but did not get run when SELECT'ing. Is there any way to
force BAISC subs to iconv selection criteria?

Thanks much!

Tedd

Well, just about anything that can be directly ICONV'ed to get an internal
format should have the output mask placed in attribute 7.

I donno how many dictionaries that I've corrected because people don't
understand this little rule. Date, time, decimal conversion, etc should be
place in the output-conversion attribute. Placing such things in the
correlative causes ACCESS to converted the values to with processing of each
item, where as the output conversion the value is converted during
compilation of ACCESS statements.

Also try placing a date conversion in correlative and see what sort of
sorting happens. Because the conversion happens with the processing of each
item, the sort happens based on the text of the dates and not the internal
numeric value.

Hope this is clear.

Regards,

Dale

"Tedd Scofield" <tedd_scofield (AT) hotmail (DOT) com> wrote

Ted, you've stumbled on one of the fundamental truths of Pick

Attribute 7 is bi-directional, here is the rule:
If you can type data, run it through one conversion, and then run it
through another to get back the same sort of data, then the conversion
belongs in 7. If you apply a correlative which fundamentally changes
the value of the data, and it's apparent that the data can't convert
back, then it belongs in 8.

It goes deeper:
Attribute 7 is used to convert input to internal (or "another")
format. AFTER that step, the system goes through Selection, then
Sorting. Then the conversion is re-applied to the Output. The
Attribute 8 correlative is only applied to file data for selection and
sorting, not to command-line input, and the output format is the same
used for sorting.

Some processor codes can be used for both 7 and 8. For example, it's
interesting to use MCT on 7 and 8. Follow the rules above to
understand how the input would be treated and what the output would
look like. Using these rules it will also be obvious why dates always
go in 7, never in 8, unless your data is stored in external format
which is asking for trouble anyway.

Any help?
T


"Tedd Scofield" <tedd_scofield (AT) hotmail (DOT) com> wrote:

Thanks for the informative answers guys!

So if I write a conversion subroutine that works in an oconv/iconv and
I call that routine in attr7 of a dict, shouldnt ACCESS try to iconv
selection criteria through that sub?

Not neccessarily.

Access reads the dictionary items of the fields you want to display/select.
If you write something like

select File with AA = "123.45"

But your data looks like 12345 or 123450 or 1234500. Depending on your
CONVERSION code, it might be any of those.

The system has two choices. A) convert 123.45 to intermal format to compare
with your data, or B) oconv AA of each data record to output format to
compare with the 123.45. The smart choice is to convert your entered data
once instead of 1000's of conversions.

If it's a simple choice, like D or M, the system makes the leap for you;
otherwise it doesn't. I wouldn't expect a complicated CALL to work like
that.

Mark Brown

"Tedd Scofield" <tedd_scofield (AT) hotmail (DOT) com> wrote

Mark Brown wrote:
So how does the system make its choice? Does it have a set list of
processing codes it will run entered data through an iconv? (If so,
where does one find such a list?

Thanks for bearing with me yall. I appreciate the help here.

I'm finding that these "fundamental truths of Pick" are more like
carefully guarded secrets. Pity, because this is the good stuff about
PICK imo.

That's always been one of the major complaints about "Pick" is that it tends
to be very esoteric. You either know or you don't and there really isn't
any place (except here, maybe) to go to find out. It's passed down from
master/mistress to disciple from generation to generation, along with the
secret hand shake.

I know how it works internally because I was up to my elbows in PVA for
years; but they've got my non-disclosure agreemet stashed away in a safe
somewhere just waiting for the day I let something slip. We like to think
RD ignores this site, but they don't. And they've got long memories.

Suffice to say, the system is smart, but not too smart. It has to act the
exact same way every time, so it takes the shortcuts that work everywhere.

You can look at a D/2 or MR0 and pretty much be assured that they are date
and numeric conversions, the two things that the system has supported since
day 1. You can't look at a CALL BLAH.BLAH and tell much from that. So the
system will ignore it. It will convert your "123.45" into 12345 if there's
an MR2 because, as I said, it's easier to do that once than to convert all
the records to compare with what you typed exactly.

The new "english compiler" got smarter, to use indexes and quoteless
parameters (with something = stuff instead of "stuff"), but again, those
are things done up front before the actual selecton process. Eventually,
the system has to scan records and compare things. The less of that it has
to do the better.


Mark


"Tedd Scofield" <tedd_scofield (AT) hotmail (DOT) com> wrote

Tedd Scofield wrote:
So you're saying that "dd/mm/yy" is /not/ human format? Think very
carefully before replying. <g>

Just about anything that makes sense to be applied in reverse can be
used in this way. Obviously this does not include G(roup extract) codes
T(ext extract) codes and the like, but does include most of the M types
(including the ever-popular MR2).

This is /important/. You /need/ to know this stuff, or Access simply
doesn't make sense.

BTW, make sure your date dictionary items ar right-justified or they
still won't sort correctly.

Cheers,
Luke

Tedd Scofield wrote:
There's your problem right there! It's NOT an output conversion
attribute, just the V/CONV attribute. To quote the Reality manual on
the subject "Used for processing values specified in an ENGLISH
sentence (input conversion), or following sort and selection processing
before output (output conversion).".

Hope this helps put things in context for you!