Thanks, David. Lauren and I have contemplated an article on usage patterns for TEXT TO, but we've both been too darn busy to commit to it.

As a rule, we strongly prefer the delayed merge strategy-- TEXT TO , followed by subsequent TEXTMERGE() -- over the use of the TEXTMERGE clause. First, it can avoid the dread "textmerge is recursive" error, which is easy to trigger in a framework or application that does lots of text processing, such as in web applications. Second, it lets you build the string separately from when the merging occurs, and possibly in a different component. This even means the data source need not be open/selected/etc. when the string is built.

-- Randy

>Randy,
>
>Great idea-starter post, Randy. Many people forget (or have never realized) that TEXT TO and TEXTMERGE() (or TEXT TO with the TEXTMERGE clause) can be great html-building tools.
>
>>It's pretty easy to do this yourself. The basic idea is to use control names that include the PK of the record as a suffix. So say your table had one text field called TITLE and one integer PK. In a SCAN loop, you could write something like:
>>

>>TEXT TO lcRow NOSHOW PRETEXT 3
>><tr>
>>  <td><input type="text" name="title<<PK>>" value="<<TITLE>>"></td>
>></tr>
>>ENDTEXT
>>* later...
>>SCAN
>>  Response.Write(TEXTMERGE(m.lcRow))
>>ENDSCAN
>>

>>Similar processing on the request side. Easy to generalize this to a class, or whatever.
>>
>>-- Randy