If I understand your answer correctly, there is no way to handle memo fields larger than 255 characters in length with TextPipe and that's it.
Bottomline what you say is: look at another SW to do that. Tell me I did not get your message correctly.

In the meantime I found the following (clumpsy) workaround: instead of using left(MyField, 500) use: mid(MyField,1,250), mid(MyField,251,500) (add more if needed) And then use a filter to put the separate fields back in one field by restricting on those fields and removing the field delimiters and t...

TextPipe current version: 7.6.3 Sorry had other priorities. Finally here is an answer on your question: the field is a memo field. I come back on it because there is another odd problem with this type of data. Besides the "Error-Invalid variant operation" problem, if I use my workaround it will work...

I just updated TextPipe Pro from 7.0.something to 7.4.2 and I am getting an "Error-Invalid variant operation" which I did not get with previous version. The filter is getting data out of an Access DB with an SQL statement in the trial run area. I could solve the problem by changing SELECT T.Desc FRO...

I receive 'BLOB' as a result of a 'count(status)' in my SQL select statement. TextPipe's Help says to try to use a subfilter with 'mime base64 encoding', I tried many of the possible encoding choices finally I got my result just using 'SUBSTRING(count(status),1,100)' instead of the 'count(status)'. ...

I had no time to look into it before now, but I finally upgraded to Textpipe Pro, had to learn how to use VBScript and lost most time finding out how to pass data to a Global variable and getting it back on the line level. By the way, it is documented and a search in the help with 'global variables'...

Textpipe is OK but I wonder if I can do the following : I have a file consisting of a header and a number of detail lines. I have to find some values in the header part and put them on each detail line to make a CSV for another application. I've been searching for the whole WE and could not find a s...