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

>>George,
>>How is the array populated? From something passed from Powerbuilder or directly from a table?
>
>PB is populating the necessary properties required to make the calculations. In my testing, I use the same SQL Server tables via remote views.
>
>>WAG, but since it doesn't work in PB and it does in VFP, maybe variable datatypes have something to do with it. One suggestion (I'm full of them today) would be to attempt to use your COM component from another IDE that uses strong typing (VC++/VB) and see if you get the same results.
>
>Long time ago, in galaxy far, far away...whoops...just it seems like that.:-) Anyway, I wondered about that myself when this was first starting, but until a week or so ago, this wasn't happening. In thinking about it, even though it's an in-proc, still the memory management and mathematical manipulations should be within an address space controlled by the run-time library, and as such, I would suspect that it would be impervious to whatever typing the calling environment had. However, I haven't bothered to prove that feeling, so perhaps it's time to pop open VB (VC++ would be too much work for this), and go from there.