Modifying real fields in automatic (was Re: Some Sort of ControlFrom The Browse Screen)

John Esak john at valar.com
Fri Oct 22 11:28:29 PDT 2010


Good for you George... I say stick to your guns. :-)

As for assigning values to real fields on the automatic table, no I'm afraid
you are wrong in all cases, since the record is NOT locked and assigning a
value when you don't have complete control (and lock) on the record is, wll,
I'm sorry George, but it's bad programming. You can push the point as long
as you want though. Unhappily I think this makes it impossible for you to
ever "win" the debate.  But, it is fun to hear you go on with various
defenses.  If you don't "get" the basic reason why you are wrong, then there
is no reason to go on, you're right, let's go on with WRITE. :-)

By the way, in your scnario, two peopole asccessing the same record at
different desks, which one do you think will be dealing with the "correct"
data for field 5?  The first one, the second one?  And if one of them sort
of simultaneously changes the value of field 5 while actually in another
proces... Say in update mode... Who then is seeing the most correct version
of field 5?

Never mind, that would require an answer.... Truly, I don't mind dropping
this. 

By the way, kudos for coming up with something in 15 minutes that does the
job... Well, to your measure anyway.  That's pretty good... I really did
think it was impossible. But, to be honest, if you look over the thread, I
think it was Scott himself who thought of a workaround before you.  At least
in my sequential reading, I saw his solution first.

But, you are right, my bad... I absolutely did say I thought it was not
possible at all... And it *can* be done in the way you suggest.  I only
admit that because, if you were ever to rewrite it as Ken suggests,
correctly in INPUT processing, than you truly would have found a solution
where I did not think of one.

(In my defnese) unfortunately, I gave my several responses in less than 10
seconds each... Not 15 minutes. :-)

John

> -----Original Message-----
> From: flowersoft at compuserve.com [mailto:flowersoft at compuserve.com] 
> Sent: Friday, October 22, 2010 1:10 PM
> To: john at valar.com; filepro-list at lists.celestial.com
> Subject: RE: Modifying real fields in automatic (was Re: Some 
> Sort of ControlFrom The Browse Screen)
> 
> > Well, I just have to ask. Why are you pushing your point?
> 
> The only point I'm trying to push is that you should never say never.
> 
> When Scott first posted his question, after several replies, 
> in one of your
> last posts on the matter you said:
> 
> " I don't think you can do what you want to do. I think Ken 
> or Ron would
> have piped up if it was possible."
> 
> I gave him an answer that does exactly what he wants or 
> wanted to do, took
> only 7 lines of code and so far Ken nor anyone else has shown 
> where the code
> I posted would create a problem in this particular scenario.
> 
> Although assigning values to real fields in automatic processing might
> create problems 99% of the time, in this particular case, 
> having the code in
> automatic does not cause a problem.
> 
> Like I said before, I'm sure there at least 50 different and 
> better ways to
> solve his problem.
> However, all the ones I saw posted wanted him to take a 
> totally different
> approach to the one he was considering.
> I tried to give him one that did not force him to re-consider 
> his whole
> approach to the problem.
> 
> "See I never thought that I could walk through fire.
> I never thought that I could take the burn.
> I never had the strength to take it higher,
> Until I reached the point of no return."



More information about the Filepro-list mailing list