>> The practice of using natural keys also leads to the natural need to use a compound keys (for many tables, the natural key is the combination of several fields), which at the very least leads to inconsistent key strategies for different tables, and at the worst creates all sorts of nightmarish problems in queries and updates.
>
>I've been hearing a lot about nightmare, but failed to encounter real nightmires. I'd like to ask in your own words "Examples, please" ?

Ok, how about a framework routine that automates the task of retrieving a single record by its PK- if some of your tables have multiple keys, you can no longer have a generic function for this. Same with any RI builder and generic Query builder that is deisgned to handle things generically.

Also, every update and select statement has to double its WHERE clause to find the correct target record.

>>(BTW- Your example of a holidays table isn't really a good one for this, because there are different holidays for different companies/ countries, and they are likely to change- the list of days in a week or months in a year, however, is not likely to change)
>
>I'm talking about holiday's which apply to the system its in. The PK is a date, if you add a surrogate key, how would you force RI rules ?

I don't follow you here. Are you confusing natural keys with real PKs? I have never said that the database is not the place to enforce uniqueness- IOW, I have no problem with the use of candidate keys...

>>FWIW, the more I use server databases like SQL and MSDE, the more put out I get with the quirks inherent in VFP data. The Deleted records issue, the corruption issue, security and all that just make VFP tables look less and less attractive especially now that the SQL engine gives us comparable performance.
>
>That's personal. I'm not in server (R)DBMS at the moment because I mainly develop standard packages which have to run on minimal costs per seat and minimal administration.

MSDE is free, and requires less maintenance than VFP tables.

> I don't think that it's a valid argument to dismiss development on the VFP engine because most of the experts or elite does not use it all that intensive.

Who said anything about experts? I said I am beginning to like server databases more because of their features.

> I'd rather see some figures about the percentage of VFP developers using or not using the VFP engine as the main database engine.

I don't think this would tell us much. There are probably lots of people writing new applications with SAY/GET, but that doesn't mean we need a more robust SAY/GET.

IMO, the value of the VFP database engine is its speed and its price. It's weaknesses are many. Now that we have alternative engines with similar performance, same price, and none of the weaknesses, the reason pool for not switching is drying up fast.

FWIW, I am still doing some new development with VFP data, but I hope to not be in a few years...