>Between the 2 of you i am going to figure this out. <vbg>
>
>well that is starting to make sense now!
>VERY simple and deffenetly not programmer worthy spoken, you could compare this process with the sorting of the start menu in windows.
>
>the 'programs' in the start menu are only short cuts (links to the data of the sql table). when i sort the start menu, all i realy do is rearange the shortcuts on the hd rather then rewriting and moving araund the actual program file.
>
>Now that makes sense!
>
>BUT, why can i not have more then 1 clustered index then? semse to me, that i could have multible 'columns' with shortcuts?! ergo: have multible clustered indexes.
>
Gunnar,

What you describe is a regular index not clustered. You can say that record # in VFP table is a clustered index because you can access any record by it's key (record #) or read records sequentualy in the order of the key. The clustered index in SQL Server has the same properties: record can be accessed by it's key or they can be read sequentialy w/o using index itself.
If SQL Server stored the clustered index data in the physical order (as VFP table) than INSERTING/UPDATING/DELETING records would require to much work because to much data would have to be moved around. Imagine that instead each record has a pointer to the previous and next record in the clustered index - double linked list. Actualy those pointers are stored on the page level but it doesn't make big difference. Managing those links requires extra work for SQL Server also but not as much as with moving records around.
Theoreticaly you could have more than one clustered index if SQL Server provide more than one Back and Forth links on each page but it would require even more work to update them.