>>>COM provides a set of standard mechanisms that allow the client to explore the exact nature of the interface at runtime using a common set of services. DCOM is nothing more than a mechanism for making a COM interface available for a server process running on a machine other than the local client; it allows you to explore and access the interface in the same way that you would if the COM server were running within your process' memory space, or on your system as a separate process. From the client app programmer's POV, it doesn't matter where it runs.
>>
>>Sorry to bother you again... but I'm very new to these terms... Theoritically i've understood little bit... But can u pls Tell me any Programs / Softwares which uses this mechanism....
>>
>>I'm asking this bcos I want to chk whether I'll be using any of these in my future projects...
>>
>
>If you use any ActiveX controls, you're already using locally-deployed COM objects in your application; there are literally thousands of products based on COM that you may or may not use. DCOM is an issue whenever you have a COM object that needs to execute on another system; in most cases, these are developed on a custom basis. Any time that you have a COM server where it'd be better to eploy the server on another machine and only make the interface available at the client end is a candidate for DCOM; you can develop an OLE server and deploy it locally, and then move it to a different machine and not change you application's code, since to you application, it doesn't matter where the code executes, the interface remains the same.
>
>Any time you take an n-tier approach, COM provides a mechanism for devleoping the middle layers to provide an interface accessible from an app without knowing what's going on it detail; it provides an abstraction of the problem. It also proviudes some flexibility in development; you can make changes in the front end, or middle tiers, or back end, without changing the other layers, as long as the interface that provides the problem abstraction remaoins the same.
>
>DCOM is a good option where you need to hide the details of the internal process. For example. many people have an issue about database security - they want to have a table containing login data and permissions as a part of their application, but VFP doesn't have built-in security. What's really needed is a security interface, where you tell it a userid and password, and it validates that. If the data is stored in a table accessible to the application, then anything that can access the .DBF can read the data. By using DCOM, and only having the COM server open the security data table, the problem is fixed; you talk to the COM object, and it executes remotely. It opens the security data, processes the request and reponds - the application, anbd hence the workstation, nbever has the security table open itself, so the risks assocaited with making access available to all users goes away - if a table can be read by a station, it can be copied at a minimum, and deleted or altered in some
>cases, but if that table is never made available except to the security object run on a different machine in the guise of a diffferent user, that problem goes away.
>
>For me, I have written a number of COM components to deployed so that the guts of many proicesses are abstracted, and so that I can revise how and where the abstraction is deployed with changing the application, or allowing me to access the abstraction with a different front-end without having to change the business rule implementation. the same business logtic can be accessed from a VFP app, a VB app, a web page; you address and access the COM object which provides a standard abstraction in a language and location-independent fashion.
>
>Microsoft has a ton of white papers out on their web site; if you go there and search on COM or DCOM, you'll find thousands of references. If you want to take a course, you might want to contact Developmentor regarding their Guerilla COM course (it's targeted at C programmers, and probably represents the toughest week I've spent in a course in my entire life, but I got up to speed for developing COM objets in a big hurry; it was well worth the ~ $2500 for the course for me) or their VB-related COM courses - they don't have an equivalent targeted at the VFP marketplace.
>
>It's a huge subject, and there are lots of books and articles. I'd start by looking at back issues of FoxPro Advisor and Foxtalk if you want VFP-related stuff; several books out from hentzenwerkes, including Marcus Egger's Advanced OOP book and Effective Techniques fro Application Development with Visual FoxPro 6 by Jim Booth and Steve Sawyer (from the standpoint of books on VFP6, this is my choice for the second most significant book available to the VFP6 community, right after Hacker's Guide, and from the standpoint of learning VFP6 and OOP, a truly remarkable piece of work) both discuss the concepts of COM and DCOM from a VFP perspective; if you could get only one book as a starting point and are comfortable that you know the fundamentals, I'd get Effective Techniques and read it cover to cover several times.

Thanks a lot for taking out your time and giving me all these helpful details...

Actually unknowingly i'm using com server (i guess), i'm transferring few reports in word & excel using ole (i.e. also ole server, Right ???)