>We are working through the MM.NET 3.5 jump starts. I am doing the business objects exercise and trying to follow what it does.
>
>In Step 6: Enhancing the Order Business Object we declare this.PrimaryKey = "OrderID", this in the Order.cs class constructor.
>
>What if you are using non-clustered indexes with unique declaration in order control your primary keys, rather than clustered indexes. Pretty much all our data revolve around use of an institutional identifier (like soc sec nbr, but not), so I will NOT have a contiguous set of numbers, nor ability to control assignment of this number. Clustered indexes on this value would not be a good idea. Thus our initial data model using non-clustered indexes with unique.
>
>How will the MM.NET framework work with this? Does this.PrimaryKey have to be a true clustered index?
>
>Thanks,
>Ron.
>
>Ronald D. Edge
>Director of Information Services
>Indiana University Athletics
>http://iuhoosiers.com
>
>"You've got to be very careful if you don't know where you are going,
>because you might not get there."
> “When you come to the fork in the road, take it”
>--Yogi Berra

Ron, I'm still using 2.4 but I think the issue is the same. There are a number of things that just don't work very well without a primary key. I generally just add a primary key assigned by the system and keep my other unique indexes. It doesn't get in the way. In these days of increasing identity theft, it's also probably a good idea to have another key for linking tables that's not an identifier used for any other purpose. I resisted the idea at first but, once I got over it, I find it does make life easier.

Go Hoosiers! I'm looking forward to a great basketball season next year.