Ed,
>>
>>Let's me get all of you more info about this case. My collegue created a form, which allows our users to specify their selection criteria, which could be very complex and different. He created a preliminary form and then switched into error handling. At this time I got an assignment to fill this form, and do this in his manner. Ok, I did it, created a lot's of my classes, changed and fixed several problems in his classes, etc. In all his application he uses conception of save-restoration in meta-files. He uses macro-commands for that.
>>I haven't studied all his code and innards, but for this particular purpose, I believe, he uses something like:
>>&selectcmd;
>>&joincmd;
>>&wherecmd;
>>&intocmd
>>
>>Suppose, wherecmd would be more that 255 char, what should we do? And, of course, it could contain space in quotes, like street="Beacon st"
>>
>>It's one problem.
>>
>
>Nadya, I'd suggest one more approach if you have VFP6 SP3. Try creating the SQL command as a command or series of commands in a string, doing all the macro-expansion necessry while building the string. Write that string to a temporary .PRG file. VFP6 SP3 can compile a .PRG on the fly using the COMPILE command. Now invoke the compiled code with DO MyCompiledProgram. This will avoid many of the macro expansion size limits.

Yes, you're suggesting an interesting approach, but I can say, that one of our programmers already did it this way. He generated a program view_sql on the fly (using textmerge, I believe) and put it in Windows/temp directory. It works fine, but, unfortunately, his app contained so many other bugs and problems, that we completely redesign from the scratch. But his idea (and the same yours) is much better, than beating on this limitation. I beleive, we would better use his old code for this purpose with some adjustments. The only thing I'm really upset is that we should spend more time, changing the current code. It's too bad, that our company has several contractors, each of them has his/her own design style, and, sometimes, even doesn't study the code of his/her predecessor. Now we're doing RE-Engineering, and my manager even had a nickname "Endless Re-engineering" :)

>It has several payoffs. If you need to do several things, you can build the entire sequence of operations into your 'on the fly' procedure. You can create variables as needed scoped to just the SQL Select block that you generate. And you can save the generated code files so that they're avaiable at another time, and can debug them without the unusual behavior sometime encountered with macro expansion.
>
>Lots of things make this approach useful. You can add code so that when run from the developer's station, the debugger can be invoked, to let you inspect what happens. If a user says the query the constructed didn't work right, you can look at the code that was generated easily. You can use this to build libraries of common user queries, too.

Great idea! Thanks a lot.

>
>>>>Just now I got this error message. I know why it happened, it's because I choose lot's of items in multilist, which affect on Init method one of my other controls. I think, it's VFP limitation 255 char on the macro string. So, my questions are:
>
>Again, putting the values into a cursor and using an IN (subquery) may help with some of the length issues. There's no limit on the number of records in a subquery AFAIK.

You're right, of course, but again, it would requir too much changes in our classes :( Ok, I'll discuss this with my collegues, and perhaps, we will change it this way. Very pity, that we're waisting our time and money, to design and redesign :(((

Thanks for all these ideas. They will not let me to sleep well this weekend :)