>>>>Interesting. So what would make a DLL perform math functions differently than a regular function call?
>>>
>>>You got me, Fred, I dunno. Or as the Marquie deSade's girlfriend said when asked why she stayed with him, "Beat's me!".:0)
>>
>>< g >
>>
>>>
>>>Seriously, the fact that I've been able to independently replicate it shows that it's there. At first, I thought it might be something to do with integer math. One of the tables contained two integer fields that were multiplied by one of the functions to return the result. Changing them to good ole numerics didn't change the result. So as the politician said when asked where he was when out on the campaign trail, "I'm stumped!":-)
>
>He's one the "stump"< nudge, nudge >
>
>>Does it ever work, or is it a hard failure? Does it work on some machines/OS and not others? (grasping here) Is there an HP printer in the building? < s >
>
>Yeah, it worked as it was previously and you've given me a thought here for testing which I'll have to pursue. Grasping at straws myself here, but that TRANSFORM() problem kicks in at .6 in the loop (in the KB article) and this particular style has a width of 145.6. Coincidence? Don't know, but that's where my testing will come in. Very few styles have this tufted width. While there's a pretty wide range, this width is only at one of the five plants involved.
>
>As for the HPs, yep, we're loaded with 'em. I guess I'd better call on Raoul for a fix.:-)

George,

Did you try with old plain STR()? :) Also, could it be the problem in SET DIGITS, SET DECIMALS, etc. They could be different in your DLL and your test form - just guessing...