Patrick:

A SQL table with 70 fields and millions of records is not uncommon. My answers to your questions:
1. You can restrict the number of records returned in a query with the "TOP" expression in the select statement. You need an "ORDER BY" clause for the "TOP" expression to work. Check your Books On Line for more info on that.
2. This is how: "Select myfield from myTable where myKey = @myParameter". Notice the "@" symbol denoting a variable. In MS SQL Server, all variables must be declared before they can be used. Unlike VFP, MS SQL Server enforces strong type casting: when you declare a variable, you must also declare the datatype and make sure the value stored in the variable is of a compatible data type.
3. Joins are always expensive. Querying a large de-normalized table with proper indexes will always return data faster than querying a highly normalized table that requires multiple joins even with correct indexes.
4. http://www.sqlservercentral.com/ is a great site for SQL developers. It is to SQL what the UT is to VFP developers. Check it out.

HTH

>Hi everybody!
>
>I'm working on a project that is expecting regularly one or several million records in one of the tables that - unluckily - has got some 70 fields. If you ask me if I don't know anything about normalization, that is not the reason, but it would cost me no little time to build somewhat complex sub-catagory constructions to reduce those (time which I don't have until the deadline for the first release).
>
>Now my question: Who has got experience with this. Is it no problem? (I worked more with VFP databases which therefore are more easy for me to assess than the Sql Server ones). Am I going to run into serious performance issues?
>
>1. How is it to select an average recordset of some hundred (max 2000) records)?
>2. How is it to select one only record "WHERE id = value"
>3. What is the difference of a SELECT without joins to one with a good number of joins to small key tables?
>4. Any tips to do it rather right than false?
>
>Patrick