Linda,

I understand the reasoning, but am leery of the overhead of then associating the 'real' keys with the generated identity value, which would then need to be the FK in this case 15-20 child tables. It seems like I am adding a lot of programmatic overhead just to translate anyway, as I still must maintain uniqueness of the actual identifier as well as story them, after all. And they are stable values, and natural keys. I just talked this over with my programmer (I am migrating from yearssss of VFP, he is learning from almost scratch), and it occurs to me that the specific datasets I am dealing with, e.g. about 7,000 records in the parent, more or less in the child, do not actually undergo that frequent add of new records. We are going to do some tests on what happens adding records when primary key is built on existing natural values. It might be I am willing to take performance hit of a couple of seconds.

I do however wish the non-clustered unique index could be leveraged as the PK.

As for the Hoosiers, it will be be better next year. The recruiting class is looking very, very good. One player from this year has left, there may be one or two more dropouts. It is a serious rebuilding phase for a battered program, but I am optimistic with the new coach, Tom Crean.

(P.S. How the heck do you make a reply quote the original message? I can't figure some of this interface out.)

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