>>>>>>>>>>>>>>>>>>>
>>Sure, if it's properly written using an N-Tier architecture.
>Wouldn't you agree it would be fairly difficult to implement improperly written n-tier objects. ARe there conventions for the 'n' in n-tier. I mean when:
>n=1 is that a client call to connect?
>n=2 is that a server side client connection object?
>n=3 is that a backend, like sql, etc?
>What does 'N' mean?
>Regards
>Terry
>>>>>>>>>>>>>>>>>>>

Terry,

I see you already got answers so I'm not going to repeat. To answer your question, N means any number, of course.

The "standard" (not counting Client/Server architecture or 2-Tier) used to be 3-Tier systems, but a lot of enterprising minds figured out that 4 is maybe a better number.

Front-end: (fat-client, thin-client, web-enabled cell phone, whatever)
Middle tier: contains you business rules
Middle tier: a connector to the back-end database (if you separate from you business rules (BizObject) then it's 4 tiers)
Back tier: database

The reason for a separate database connector in the middle tier is so you can swap databases with minimun changes. You could a module that talks to SQL Server, and swapo it with one that knows how to talk to Oracle, or whatever.

You could have one that knows how to deal with a database through ADO and another one that knows XML.

You see why N-Tier and not just a 'fixed' 3?