>>SNIP
>>
>>>QUESTION:
>>>What could be a reason to use three-tier architecture with an OLE Server rather then calling SQL Server stored procedures?
>>>
>>>I know one is that i can write business-rules in my familair language VFP but i wouldn't realy care to learn SQL Server language.
>>
>>SQL Server SPs are somewhat limited in what you can do with them. Using COM (Component Object Model) components (what used to be called OLE servers) not only allows you to use your preferred development language, it also allows you to move the processing to high-powered servers via DCOM (Distributed Component Object Model). But don't make the common mistake of thinking you have to have 3 servers for 3-tier systems. The components could easily be run from the same server that has SQL Server installed on it, so long as the server is beefy enough. The n-tier refers to the programming model, not the hardware model.
>>
>>>I have been thinking about a possible pro of using multi-tier architecture but i am not sure this is true: Can i develope OLE objects like navigation buttons where for instance the skip button is disabled when the end of the file is reached and use this object in Visual FoxPro Access and Visual Basic?
>>
>>Components in n-tier solutions are generally used to handle business logic. They expose methods that accept parameters and then process data based on the parameters and any business rules. The component then returns whatever is required: actual data, information about data, even HTML. What you're talking about with interface elements are really ActiveX controls, not n-tier components.
>>
>>>I realy need to know the pros and cons in order to make the right decission.
>>
>>>Thanks for any reply,
>>>
>>>Marco.
>>
>>Let me briefly explain what we're currently doing with components to give you and idea of what I'm talking about.
>>
>>We produce applications that deal with a federal data structure for holding labor market information. The structure consists of about 20 main data tables and around 125 various lookups. We currently have a VFP app that runs 4-tier and we also produce a web based version that also runs 4-tier.
>>
>>We have components whose sole function in life is to query the various data tables. These components are called by other components that then return the data in the appropriate format, whether it be rows for VFP grids or HTML tables for the web app.
>>
>>The beauty of this solution is that the called data components can be used by either app because they are not client specific. They accept the necessary parameters and return the data (we use ADO). The calling component is client specific and knows how to return the data. Also, any future app we develop against this data structure can use the same data components. Development heaven!
>>
>>The components run on the same server as SQL Server and the client app, whether its a VFP app on client workstations or a web server, communicates with the components via DCOM. The great thing about this is that if you make a change in the component it only has to be updated in one place (the server) instead of on all the clients. Maintenance heaven!
>>
>>So the 4 tiers here are: The data, the data access component, the client component, and the client app. The first 3 tiers run on one high powered server, although the components could be installed on a separate server if necessary to distribute the processing. This of course would also be dependent on available network bandwidth. We also use Microsoft Transaction Server to handle our components. I won't go into the details of that here, but along with handling tranactions, MTS is also a good object broker for COM components. MTS comes free with the NT Option Pack for NTServer 4.
>>
>>You can get information on COM components at www.microsoft.com/com.
>>
>>Well, I hope this helped. Sorry it's so long winded, but this is really cool stuff! I'll be happy to answer any other questions you have.
>
>I'd like to add a couple of notes here. First, SQL Server can take a performance hit when other things are running on the server. If you see that SQL Server performance is not where it should be, try moving Automation Servers, MTS, etc to a different server. Second, one of the cool things about MTS is that you can write all your code single user. Because MTS handles transactions for you, you don't need to worry about multi-user code, which simplifies coding.

Well noted! The single user stuff is great!