>I've been using append memo to do a lot of things, it's a much faster operati on >than it would seem, huge files just pop in there so fast, and they write bac k >to disk equally fast. I know, and I do so; there's been one exception to the rule so far. I had to do FPD reports on PCL laser printers, and do it a lot; there was absolutely no time and no way to convert all the reports to use the proper printer driver, or to create double versions of reports. There were simply too many of them, and mostly stuffed with ESC/P2 sequences hardcoded in many imaginative ways (sometimes Chr(27)+"M", sometimes a variable defined in a calling program, sometimes a function which returned it, sometimes the ESC character directly keyed into a literal...). So I leaned on the fact that we send all the reports into a file (in DOS), and I have two routines there, PrOn() to open the file and set the environment, and PrOff() to close and reset. The other one now checks if there's a PCL driver active, and creates a dummy cursor with a memo field, to append the file into, to do the conversion on, and finally to spit it back into the same file it was appended from. It does massive StrTran(memo1, EpsonEscSeq, PCLEscSEq), and the .tmp files seem to grow substantially and eventually use up all the disk space - it choked a machine with sure 200M free on the temp drive and on a report which was some 60 pages long (a list of streets and their intersections in a city of 200,000 population). I ended up with chopping page by page from the memo, converting, and FWrite()ing it back to disk one by one; there's no gain or loss on speed, but it doesn't break anymore. There's another routine, later, which takes this file and strips all the PCL sequences so the file may be viewed; the approach is similar. The moral of the story is that manipulation of the memo is the third best thing after sex and flying, but it has to be used with some measure.