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

Yeah, but who cares?

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

>Further, I don't like the solution you've choosen because other connected applications might violate these rule.

So you code _all_ of your business rules in the DBC? No? What about other applications connecting? But for some reason this rule is more important than all the others that you put in your application?

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

No need for discussion. You already stated the point that kills your argument and lost for yourself.

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

Yes, because the developer sets up the relationships, and FoxFire! uses the developer built meta-data to construct SQL.

>>No. This leads to a heterogenous strategy.
>
>I would call rather call it: Best from both worlds.

You say tomato, I say crap.

>Like I asked Chris, then what objection do you have by storing the articleno in a field "Art_pk" with a caption of "Articleno" ???

It changes the situation because articleno is a character field, and its source is not NewID(). So should I also begin storing SSN in People_PK? and BadgeNumber in Officer_PK? That's just plain goofy.

Walter, even if your plans did work, you're proposing piles and piles of workarounds to justify a strategy that has gained me nothing. (Yes, I have been listening to your 'advantages' and not a single one of them makes me care).

>With inconsistency comes exiting,

I guess you could say that guessing games are exciting. Personally, when it comes to deciphering an application's architecture, guessing games just piss me off.

>creativity and

=MESSAGEBOX("Hit cancel to proceed", 1,"")

Creative eh? And inconsistent!!!

>efficiency

No, not efficiency. Effeciency is when you can look at an application you haven't touched in two years and know exactly how it's architected, because your architecture choices didn't depend on your mood that day.

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

Put a candidate restraint on the city lookup. What's so hard about that?

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

Like I said, that's just you.