>>the advantage of primary key is better database integrity > >Actually, I think that you're re-inforcing the point I was trying to make< s > (the "Blank" id was just supposed to be a plain example). > >Ideally, if you use a stored procedure to generate your id, you shouldn't have a problem with duplicates hence no absolute requirement for the primary/candidate index type. > >If though, by some weird "bug", "anomaly", or "undocumented feature" you should get duplicates, it's a lot more difficult to handle with Fox trying to grab control than if you do the proper checking yourself. but iwth primary key you will not get a duplicate - the new key will be regected, without something slipping through your checks this way I'll get an error and won't have curropted data I'd rather get an error that try to figure later where why some SQL doesn't bring the results it should I've spent time in the past with FP2 stareing at SQLs trying to figure what's wrong only to discover the the "impossible" has happened and there are dupilcate keys- I wouldn't want to do this with a database of more than 200 tables where you have queries with 10 or more JOINs and this is just one example Arnon