DCOM Help (was : RDO Help)
- From: "Narrff" <google@xxxxxxxxxxxxxxxxx>
- Date: 30 Jun 2005 09:56:50 -0700
(Reposted after editing to reflect my actual issue. Thanks, Dag!)
Hola,
First of all, a big hello to the regs (Frank, Neila, et al). I haven't
been here for quite a while now, but hope to get back in the loop, as
time allows. (Frank, still KARTing?)
On to my question : What are the limitations of creating a DCOM
component, ie: OS, permissions, etc. ?
I'm (still) designing a POS system, and had the idea that raw TCP/IP
would be the protocol of choice for either LAN or WAN operation, as it
would be fairly transparent in either mode. However, this frustrating,
time-consuming megalith of a project is nearing its deadline, and LAN
operation is found to be more crucial than WAN.
Having read about the relative merits of DCOM on MSDN, it seems that
it could be used as a quick way to allow asynchronous operations
(mainly database locking and synchronisation) on the LAN side, at least
well enough for my client to open his fourth store.
The scenario I envision is (as an example POP) : A DCOM object resides
on three PCs. The object is designed to handle record locking and
synchronisation of the databases. Each PC has a complete copy of the
data, for purposes of redundancy. To ensure this redundancy, each PC
(using the three PC model) creates a local DB object, and two remote DB
objects, one on each of the peers on the LAN. Each PC is responsible
for locking and synching records as appropriate. I could go on, but I
think that's enough information for the time being.
Granted, the TCP/IP method is still the best way I know of to do what
I need, especially as the app may possibly be ported to a *nix platform
in the future. (boo, hiss! <g>). But ... due to 'feature-creep', and
other issues, I simply may not have the time to design and implement
the protocol by the 'usage' deadline. Also, if it makes a difference,
the application has been built from scratch, using pure VB code, and
*very* few external components. Notably, and relevant, is the fact that
the database engine is also proprietary, so any solutions built into
other DB engines don't apply in this instance.
That being said, I have followed the instructions in MSDN for creating
and deploying a DCOM object, and haven't yet been able to do so. For
R&D, I am using my desktop (WIN2K), and notebook (WINXP). Every time I
attempt to create a remote object, I receive an error stating that the
object couldn't be created.
Can *anyone* refer me to an example of how to create and implement a
simple DCOM object? I assume that once I can create and access said
object, I can add functionality as necessary. Of course, the MSDN
sample did not work, so it is either incorrect, or I have missed a
basic concept or caveat.
TIA,
J. (Switched from whisk(e)y to rum, btw <g>)
.
- Follow-Ups:
- Re: DCOM Help (was : RDO Help)
- From: Steve Gerrard
- Re: DCOM Help (was : RDO Help)
- Prev by Date: VB4.0 16-bit Function declarations (NETAPI.DLL)
- Next by Date: Re: A Colon, in Visual Basic
- Previous by thread: VB4.0 16-bit Function declarations (NETAPI.DLL)
- Next by thread: Re: DCOM Help (was : RDO Help)
- Index(es):
Relevant Pages
|
