>I just want to understand WHY!

>No, no problems for now. But soon it there will be.
>The table in question now is very small about 9000 records, but because I never delete records in it will become bigger and bigger. That is why I want to undesrand.
>There is no problem to add an autoincrement field and use it (whit all others) as PRIMARY KEY, but I just want to know :-)

I don't think you cannot draw any conclusions from this example. SQL-servers cost based optimizer is ussually (I won't say all the time) pretty good at determining the right execution plan. Sometimes a table scan is just faster than multiple index seeks. In order to determine what is faster you can force a certain execution plan by using index hints WITH (INDEX = ...) and the join hints LOOP, HASH and MERGE, and just measure it in the SQL profiler. In the beginning I just thought like you that I could fully understand and predict the execution plan as I pretty much could in VFP. But SQL server is different and therefore it is difficult to always understand why it choosing one execution plan over another. Some factors (not an extensive list) involved are:

- Memory
- Number of CPU's
- The existance of particular indexes
- The selectivity of the index and the values to retrieve
- Whether an index is unique (primary or not)
- The nature of the query
- Whether certain information can by retrieved by indexes only
- The size of the tables and indexes
- The usage of clustered indexes

It is far more difficult to determine the execution plan than under VFP. That is just the nature of the beast.

I've hit many examples where a table scan just was faster than an iterating index seek, esspecially if the same records are retrieved again and again. There are many other tricks like getting the most out of compound indexes and full index coverage to speed up your queries if neccesary.