Hi Erik,

>>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.

I don't see why this is a problem. AFAIK the VFP RI builder does it. You'll have enhance your framework routine, but it is certainly not impossible. This answer begs the question: What will you do when writing an application for an existing database with composite keys ?

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

Where does the problem arise here ? In the view buider (or your eview application (I use it frequently), or programmaticly) you can define multiple key fields and VFP takes care of the rest. In other cases you can concatenate fields into a comosite index and work with the index directly.

NOTE: you seem to draw the conclusion that using intelligent keys is the same as using composite keys. Let's be clear: They are not. Using Intelligent keys in a particular table don't have to lead to composite keys. However there are other cases where intelligents keys are a better solution than surrogate keys. The decision which to use IMO is a case by case story.

>>>(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 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...

Well, imagine you've got a table where a date or timefield is unique and that when correctly entered is not (ristricts on child) or not likely (ristricts or cascade on childs) to be changed. There are childs which have foreign keys to this table. There are RI rules between the child and parent. Now add a substitute key to the parent table. Now your RI rules (you can't change a date when a child contains a matching record, IOW you can't change a date of a lesson when a student has subscribed to it) are broken and you'll have to program them in a custom way.

>>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.

>> 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.

That's because there is a fully (or almost full) upwards compatible alternative in the form of textboxes and other controls. I see possibilities to enhance the VFP database engine so, that it will be faster and even more flexible than it is right now. You can think of: Rushmmore optimizable filtered indexes, Ignore deleted records totally, Procedures that return cursors as a parameter, optimizer hints by specifying which indexes to use, navigating and querying indexes like tables, flowfilters like they're used in Navision, an performance monitor for I/O per table and indexes caused by a query, etc.

>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.

When talking about MSDE as alternative to the VFP database, you'll have to admit that there are advantages of the VFP database over MSDE:
- No size limit
- No user limit
- Easy to install (no registration, or addition dlls needed)
- Xbase approach that can be many times faster and flexible than SQL

As for the corruption. I've got about 100 independent systems up and running all over the country for about one or two years now, and have not yet discovered one instance of corruption of either the table no the indexes. VFP, when using buffering and transactions is far less fragile than FPW 2.x.

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

I'll hope that the VFP database engine has evolved into a database that has many advantages over SQL, so that it will maintain its leadership in flexibility and speed.

Walter,