Hi mike,

>I hope the bold text in your last reply wasn't representative of anger.

Oops, something went wrong. Only the word seven should be bold. Nah, I seldom get angry.

>If you're using a SQL Server backend, you don't get direct access to the tables. So the alternative viable approach you refer to doesn't exist in a C/S environment (except that one could write stored procedures).

That's correct. But i'm not using VFP to do things in a SQL-server manner. VFP is gifted with powerfull xbase commands, so why not use them ? SQL - server does not know a SEEK alike command. Does this mean we should not use it ?

>I like the KISS principle and having to re-examine both approaches for every situation is obviously not keeping things simple.

KISS ? please explain. Unfortunately most things are not simple. When getting the most out of VFP, this steps are needed. It helps me to evaluate new things, and expand my knowledge and personal framework. I've got a project where performance is a big issue. It calculates 1 year rosters and sicknesses, leavehours, etc for government personel. Calculating it in the SQL style, took about 1000 times longer than a keen xBase approach with extensively use of recursive SEEK(), KEYMATCH, filtered INDEXES, SET RELATION functions and smart algoritms. This beeing possible is exactly the reason why I use VFP. There are so many ways to optimize performance. It's almost only limited by your creativity.

>The set filter command filters tables. So why do other commands support filters too? That makes VFP much more complicated. That tendency has good and bad points.

I agree. I tend to emphasize the good things.

>Why not just...
>
>SET FILTER TO somecondition
>BROWSE
>

>instead of

>
>BROWSE FOR somecondition
>

>Is there really any great improvment by this? Both techniques are valid, but only one technique is essential.

1. more compact code.
2. Faster (in terms of interpretating the commands)

>You often use the term revert to intelligent keys. Revert implies going backwards.

In fact it does. Many people who were used to use intelligent keys are talked into surrogate keys (like Don). But when encountering problems which are difficult to solve it's better to revert to intelligent keys. I don't see going backwards as a bad thing in all cases. I also once made the step from exclusively intelligent to surrogates, but I soon came to the conlcusion that surrogates are not the mistic problemsolvers as many people want to believe. They too come with specific strengths and weaknesses.

Walter,