Possibly SOLVED Re: Now *here's* an odd problem with dclerk

[Kenneth Brody]

Quoting Jay R. Ashworth (Mon, 17 Mar 2008 21:29:57 -0400):

> On Mon, Mar 17, 2008 at 04:05:02PM -0700, Jeff Harrison wrote:
>> No problem.  You probably simply have a "44=
>> [something]" in the auto table.  Not a reccommended
>> practice - This is not filepro's fault - the
>> programmer should know better.
>
> Sure, but what *is* the result of making an assignment to a real field
> in auto these days?  Version defined?  Undefined?

In order to permit such broken software to continue to "work", assigning
to real fields in automatic is still permitted.

> And why would this interact with the selections, but not with indices?

Because you have changed the field in memory, but you haven't written it
back to disk.

For example, consider an automatic processing with:

     44 = "oopsie"

A *clerk scan for:

     44 eq oopsie

will find all records, because the record is read and field 44 is then
assigned the value "oopsie".  However, this is only the in-memory copy
of the record, as you have not (yet) entered update mode and saved the
record with that new value.

If you then go into index mode on an index built on field 44, you will
not find any "oopsie" values, unless a record already exists which
really does have that value.

Also, if you bring up a screen on any record, you will see that field
44 contains the value "oopsie", yet browse will show a different value
(the "real" value) for that field.

> Enquiring minds wanna know.

As the doctor replied when told "it hurts when I do this":

     "Don't do that."

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com