>Hi George,
>
>Do the (original) functions that return the values being compared include a VAL() function to provide the result (of either)?
>
>The reason that I ask is because of a most strange bug I reported here last week involving VAL(). While I have no idea as to the actual cause of mine, I wrote it off to some kind of RAM 'management' problem in VFP causing the VAL() to simply not execute (but not error either).
>
>No doubt the PB environment is using much more RAM, making for a possible similar situation.
>
>My solution was simple (though a tearing-my-hair-out-last-silly-shot) - removing approximately 1500+ of extraneous lines of code in a large WC process module that I had kept around as "backup" (and really did backup on me)).
>
>good luck,
>
Jim,

No, EVALUATE() is used in the one as I posted in my original message. This is used return the numeric value of a fraction expressed as a string.

I added VAL() as a workaround (see original message again), but more recent tests on smaller gauges (5/64) are failing in PB, but again not in VFP.

Larry suggested that I try another, more strongly typed language such as VB or VC++. It occurs to me that this may be being cause by the runtime library, since my tests are being done in development mode, the next step logically, I would think is to check this on a stand-alone application. If this is the problem, then I'll have saved myself some perhaps unnecessary work.

Thanks for the feedback,