>The outfit I work for, is less interested in my developing in such a way as to preserve my skills for the future than they are in the delivery of the current project running as optimum as possible. After all, we are providing a solution, and are competing vety hard to deliver a superior one. In the instant example, the SEEK()/INDEXSEEK() functions are way faster than Select SQL. This is one of the big advantages in using VFP as opposed to using VB as a front end. Anytime I can SEEK a record in a 1.5 to 2 million record table and return it within a second or so as opposed to the 2.5 to 3 minutes for a similar SELECT, I go for it, and thus am a small step ahead of my competition or at least keeping up with them.

Exactly the point I wanted to make, thanks for saving me the effort :)
To elaborate further, the classic way to include a name from a lookup table, uses a join on that table, namely

select first.code, second.name ;
   from first;
   join second on first.code=second.code

But if you have a dozen of such lookups in the same SQL statement, it will surely start to crawl. A good alternative is

select first.code, iif(seek(first.code, 'second', 'tag'), ;
   second.name, space(20)) as name;
   from first

...because it combines record by record, not trying to build a Cartesian product of it all and then reducing it to real size. I have observed the sizes of temp files going down from 50 megs to less then 1M after introducing such changes. And the speed went up by an order of magnitude.

Not to mention the situation when you can't actually have a dozen lookups in the same select statement - for what I know, we're limited to ten tables.


>When it comes time to migrate or upsize, that is the time to get busy with the SQL statements as that is the only way they will work. But until then, I recommend the developer deliver an optimized product designed on the criteria at the time of development. You will have more users happy with your product, which equals more development business in the future.

Agreed.