Hi Erik,

>>Hmmm, its not likely you would encounter a database designed by me.
>I was trying to be funny.

Hmmm, my sense of humor seems to be lost :)

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

I dont argue with you, but do you agree that the described answer is incorrect ?

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

In your case, I'd probably would handle the cryptic message and translate this in one understandable one. Further, I don't like the solution you've choosen because other connected applications might violate these rule. Now, I already can hear your say that they should connect via the business tier, but that's a total other discussion which I don't want to start right now.

>>FoxFire might do so for VFP data, but does it do this for any other RDBMS?
>There is a client server version as well.

But does it for client server data ?? I don't know foxFire that well, but it seems unlikely it will do so for all popular server DBMSs.

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

Lucky you, I've to write my own solutions in an awfull lot of cases, I don't like to present enlish sultions in a dutch application. OTOH, I do learn a lot of everything.

>>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 would call rather call it: Best from both worlds.

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

Like I asked Chris, then what objection do you have by storing the articleno in a field "Art_pk" with a caption of "Articleno" ??? I'll bet this does not change the situation nor does it violate the consistency issue. Consistent naming of fields and using non-composite keys only do not have anything to do with intelligent or surrogate keys.

In general consistency is good, but when driven too far:
With consistency comes boring, narrow views and unefficiency
With inconsistency comes exiting, creativity and efficiency

See the City example in the message I send to Chris.

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

From my view, you might be trying to use a screwdriver to pound a nail in. I don't just agree that these kind of businessrules belong anywhere else than in the database.

>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"?

Besides, that in you solution the are more xBase commands to be processed, in a SQL statement happens far more than simply looking for a record with KEYMATCH and/or SEEK. The overhead of rushmore to determine the best strategy to optimize the query is significant. I've done quite a bit investigation on this issue. For the very same reason, it may be wise for table smaller than say about 100 records to use no optimization at all. Just try it and you'll see.

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

We're disagreeing on some points, allright, but we both get different viewpoints on how to handle thing. I would say, pretty productive.

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

Hmmm, i've seen much VFP code from microsoft that uses intelligent keys. Beginners ?? I'm not willing to list the names of people who did, besides the work to complete the list, I'm not willing to involve them in this discussion against their will.

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

We can't look into the future, if we could, we would be doing something very different right now. I'm saying, that's life.

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

From the experience I have with C/S development I could only say that it would take significant amounts of time to create such an environment to do this. And still I have to see that it will be just as easy and expensive.

Walter,