Sergey and others,

I found it. It was, indeed, a system setting, but one scoped to this particular database. After banging my head against the wall a while longer, I tried a TOP n query on a different database on the same server -- worked just fine. So, it had to be something unusual about how this database was configured.

Can you guess yet?

OK, I'll tell. It was the database compatibility level, which was somehow set to 65 instead of 80 just for that database, reverting its behavior to SQL Server 6.5, which did not include the TOP n capability! You can determine the compatibility level with this query:

SELECT cmptlevel FROM sysdatabases WHERE name = 'yourdatabase'

...and you can set it to a different level (60, 65, 70, 80) with this:

sp_dbcmptlevel yourdatabase, 80

It's similar to the SET ENGINEBEHAVIOR setting in VFP, but scoped to the individual databases.

The big mystery is how this got set wrong in the first place. I had used the upsizing wizard in VFP9 to quickly throw some legacy tables and their data up into SQL Server for prototyping a project, but I just did another test upsizing to a different new database and it came through just fine as 80 compatibility. Maybe a gremlin has been playing around. Hmmm, seems like a great April Fool's joke to play on your favorite DBA.

Anyway, at least part of the mystery (the important part) is solved. Thanks everyone for staying up late to grasp at improbable, but strangely logical, possibilities. :-)

>David,
>
>It's valid query. Are you sure it's '1' (one) not 'l' (lower L)?