Erik,

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

I do, I like to see correct answers. Answer noted, thanks.

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

As far as being possible, yes.

>What about other applications connecting? But for some reason this rule is more important than all the others that you put in your application?

Business rules should be as close as the data as being possible. I don't want applications be able to violate the business rule by direct connecting to the database. Esspecially when you're attaching your application to an existing database you can't force other applications to use your business rules object.

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

Nope, an argument stated above.

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

That's nice. I'd love to see that in other products, like crystal Reports.

>>>No. This leads to a heterogenous strategy.
>>
>>I would call rather call it: Best from both worlds.
>
>You say tomato, I say crap.

Hmmm I guess you don't have respect for this statement ?? You're saying that heterogenious strategies are bad ?? I see you've got a lot to learn yet.

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

Call it what you want. Since it *is* the PK, it justifies the name.

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

That's your opinion, At least you've noted that there are. You're already a step further than the rest. Another person might 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.

Inconsistency leads to Guessing. I wonder how your drawed that conclusion. They've nothing to do with eachother. If inconsistency comes with clear good reasons which are clearly documented and noticable in code. I don't see the problem.

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

Erik, again these are really another issue that have nothing to do with an heterogenous strategy. My choices in application don't depend on the mood on a given day, but on reasoning. feel free to react this childish, it does not say anything about me.

>>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 not the question ? It's about the changes in the adress table. Please reread.

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

I doubt it.

Walter,