David,

it is character data most of the time but not always. The datatype of the field might be numeric from time to time. Since the documentation of VFP states that TRANFORM() leaves character data unchanged, I decided to do it without an IF/IIF statement (you delivered the meta statement in your answer) and transform always.

The problem I see here is that it worked before VFP 7 and didn't find the changed behaviour documented.

Robert

>Robert,
>
>If it's character data already there's no need to TRANSFORM() it.
>
>>I've built a class which parses HTML pages and replaces special tags within the HTML source with the content of vars and table fields. Worked fine for years, no changes to the classes source code for at least one year. Suddenly customers are complaining about their HTML pages beeing messed up. What happened? We delivered updates compiled with VFP 7 a few weeks ago. I have tracked the problem down to the Parser/Generator module, which contains the following line of code:

lcBufValue = TRANSFORM(EVALUATE(lcEvaluate))

lcEvaluate contains the name of a memory variable or a table field which was parsed out of the HTML source, usually this var/field is a memo which contains severeal hundred/thousand characters of HTML code generated by the app. It seems that within VFP 7 the result of the TRANSFORM() is trimmed to 256 characters - which is the reason for the mess in the rendered HTML page. In the versions before VFP 7 it worked like a charm.
>>
>>Then I tried this:

lcTransformBuf = EVALUATE(lcEvaluate)
>>lcBufValue     = TRANSFORM(lcTransformBuf)
>>

and it worked as supposed to!
>>
>>Is there anything I should know to understand this?