>>I first ask "who designed this database? Walter?",

>Hmmm, its not likely you would encounter a database designed by me.

I was trying to be funny.

>Please, stay awake Erik, this is incorrect. The join expression is longer, but there are less joins needed. In terms of performance this is a big difference.

Ok, I agree. I thought the issue was developer effort, not query efficiency.

>Conclusion, the answer: "Don't use intelligent keys, just use surrogate keys" to the question "I've got a uniquness of primary key violated error, what do i do about it ?" cannot be correct, it simply cannot: it does not solve the problem at all.

You are distracting from the argument. I did not put this answer forth, so there is no need to argue it with me.

>So the decision wheter to use a cascading delete or a restrict RI rules is not based on business rules ?? If not, on what bases do you choose ?

To be honest, it doesn't really matter, because this rule has to be written in an intelligent front-end anyway, to prevent the user from getting a DB generated (and probably cryptic) error message. So either way, my front end handles it. I could lay out a rule that says from here on out, all deletes are cascared, and that would be fine, because exceptions to this rule are handled in the front end.

>FoxFire might do so for VFP data, but does it do this for any other RDBMS?

There is a client server version as well.

>I don't have the impression that reporting tools do draw relations that automaticly.

The point is that it can and is handled by at least one ad-hoc tool. To be honest, I wouldn't be using FoxFire if it didn't do this. I would search for an alternative or write my own that did.

>So we can conclude that there are advantages and disadvantages to each approach. So would it not be wise to at least consider which to use in some particular cases ?

No. This leads to a heterogenous strategy.

>I failed to have catch your problems with a heterogenous strategy. If not using composite keys, Tell me what are your objections ?

Like Chris has stated in another branch of this thread- consistency is key. If I architected a system, a complete stranger can look at the table and field names and tell exactly what the PK is, and exactly what fields are used for the foreign key, and what tables they are related to. My framework knows how (for _every_ table) to assign a new PK and fill in all FKs when the user adds a record. I can build an entire 1-to-many n-tier data entry form/ business object set without writing a single line of code- I just set a few properties in the form and business object, and define the proper views or stored procedures for data access. If I had "chosen my strategy depending on the circumstances" I could not do this, or at least it would take an exponentially larger amount of code. With consistency comes simplicity and manageability.

>>You can also avoid buying a scooper by using your hat to pick up after your dog.
>
>eh... I'm not sure what you're saying here.

I'm saying that using a hammer to pound a screw in might save you the cost of a screwdriver, but that doesn't mean its the best choice. I don't use RI builders to write business rules.

>>No, you didn't. You just restated that xBase is faster.
>
>From looking at the code, you don't have to be an expert to see that the xBase code is far faster and far more efficent than the SQL one. Conclusing in this case it is more flexible.

Give me a break. My code sample had the same number of logical steps as yours. How do you get from this that your code "is far faster"?

>I'll wait until your answer, after that we can draw a conclusion; it's far more productive than just saying we agree to disagree.

Ok. But unless this message has changed your mind, we're still disagreeing.

>No, i'm not as I've encountered some people with the same standpoint as I have.

Produce them. :-) Besides yourself, the only VFP developers I have encountered that use intelligent keys are those that have just begun. I am not using this as evidence for the point, only as justification for not acknowledging your opinion in my posts.

End Topic One

Begin Topic Two

>In this case, I'll gather all the info needed to make a good decision. If after all it was a bad conclusion, I know the decision was made by looking at every aspect and could not accuse myself for making a bad decision. Note, that all decisions can be bad, not only the choice for a xBase database.

I don't think I was negligent at the time, but I still regret the decision.

>It will likely take more time to develop an application for MSDE (at least for me) than just xBase tables. Therefore it is not worth the costs.

That's just you. If one is used to C/S development, developing a SQL/MSDE app costs little or no more time than developing a pure VFP app.