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

[Jay R. Ashworth]

On Mon, Mar 17, 2008 at 10:59:46PM -0400, Kenneth Brody wrote:
> >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.

Yes, but in this case the field is known to actually *contain* 'N',
cause we put it there with dreport.

> >Enquiring minds wanna know.
> 
> As the doctor replied when told "it hurts when I do this":
> 
>     "Don't do that."

I'm trying to find out exactly what it is I'm *doing*, so I can stop.

That sentence defines about 60% of my interactions with filePro, come
to think of it... :-}

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274

	     Those who cast the vote decide nothing.
	     Those who count the vote decide everything.
	       -- (Joseph Stalin)