The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Embarrassed to ask, call a function on another machine

Please don't flame me. Just post links to web pages if you like. Or ignore me.

I have an MS Access database on one machine (Windows XP). I want to call a function in a .dll (specifically cdoex.dll) on another machine.


Or if I write the functionality I want, either as part of an Access file, or in VB6/Delphi compiled as a .dll, or as a .net assembly, how do I call a function on one machine from another machine?

All of this across a LAN. Windows XP clients, Windows 2003 Server.

Or can I do all this using the clipboard :/
Frank Weiss
Thursday, October 25, 2007
If I were writing a VB6 program, I would create a DSN-less connection to the database and probably create a reference to the DLL and call its public methods in my program.

If I were writing an ASP program, I would probably do the same thing.
Ezani Send private email
Thursday, October 25, 2007
Search for RPC and DCOM.

Technically what you're asking is called RPC (remote procedure call) - but you can't just call a random function from a random DLL.
It will have to be exposed by the remote system.

Also, you'll need to be able to do perform the RPC somehow on the local system - either you'll need to build your own DLL, or maybe you can use DCOM (which would be Distributed COM).
I can't help you with the details though.

Thursday, October 25, 2007
Depending on exactly what it is you want to do, I'd probably write a simple Web Service for this. Either using SOAP or as a simple Web page called via plain old HTTP.

Have the code of the service on the server call your DLL and have your clients send requests to this service and get responses back. If you use .Net for this you also get the advantages of the nice security framework.
Thursday, October 25, 2007
+1 for DCOM/RPC.

Web Services is a bit of overkill for an access/delphi app and requires you to add a web server, etc. to the machine.

Thursday, October 25, 2007
Thanks folks. This is initially for an emailing module. If I locate it on the server I can use codex (on the server where exchange is located), otherwise I have to use cdosys on each users machine, and pray it's always there, and not a different version.

So it makes sense to put it on the server. And in the long run lots of other things no doubt. i.e, this app might be heading in a 3 tier direction, albeit in a small way.

In a Microsoft environment is DCOM still the way, or should I be thinking about .net?

At the moment it's Access front end to Access back end, but soon to be Access (probably) front end to SQL Server back end.

Thanks for your help. I'd half investigated and it was looking a bit like DCOM, but I wanted confirmation/other views from people I respect, which is you lot.

Hope it didn't appear I was just being lazy.
Frank Weiss
Thursday, October 25, 2007
If you just want to send emails then consider using SMTP instead. There are several free ActiveX controls out there (google is your friend) that can be used in Access and don't have any other dependencies. DCOM is the right answer for cross machine communication but it sounds overkill in your case. It adds quite a lot of uncertainty (network) and overhead (security configuration and DCOM configuration).
JSD Send private email
Thursday, October 25, 2007
If you're looking at .NET, then it gets called "remoting."
Peter Send private email
Thursday, October 25, 2007
Doesn't .Net 2 have an SMTP client in it?
Thursday, October 25, 2007
Thanks for your suggestions folks.

This is an MS - Access application, split front end on each workstation, back end on the server. Which is pretty standard architecture.

Although implementing this in the front end is straight forward (call cdosys.dll send to the smtp server, which in this case is actually MS Exchange), I am at the stage of wondering whether I ought to be taking common functionality, especially if it isn't to do with the user interface, OUT of the Access front end and store it centrally. Hence my question (also running it on the server allows me to call codex.dll which might be useful).

It's just a thinking ahead type thing. The more I take OUT of the front end the less I have to distribute new copies of the front end. Well, that's not an issue at the moment. The user's link to the front end actually starts a little vb exe which checks for a new version on the server and moves it across. But I still have to ask the users to exit the database and reopen.

Also in the fullness of time the users will want remote access. Well, one does already, and we've handled that with a VPN and terminal services. But you see what I'm thinking.

I guess I'm trying to move towards a thinner client with a middle tier. Or at least I don't want the client to gain any more weight.

Thanks very much for your suggestions. It looks like the 2 things I need to investigate in detail are DCOM and .net remoting.

Any reccomendations between the 2?
Frank Weiss
Friday, October 26, 2007
Just for a little more perspective or info on options:

I program in Delphi and use the kbmMW remoting framework.  That framework has an ActiveX control that works as a client to any kbmMW middleware server written in Delphi.  ( )  Implementation of the server to do what you're doing is fairly trivial.  This sort of remoting in Delphi is straightforward and gets around the configuration problems you might have with DCOM.

RemObjects is another Delphi/.NET remoting framework that goes beyond simple .NET remoting.  You can do similar thing with it.  Here's a little info on it:{21972A22-0DD9-4BC3-82F2-FA1759A36934}

I don't know whether you'd consider any of those as options for your situation, but they point the way towards something else to look for:  some sort of ActiveX (COM) client control that wraps up a .NET remoting client so you can access a .NET server from VBA.

I also have a completely different suggestion that may be a hack or crude workaround but then again might work.  If your only concern is to email from a central server, why not just set up an smtp server on the central machine and have the Access clients send emails to it?  The emails can then be forwarded to ultimate destinations by the central server.
Herbert Sitz Send private email
Friday, October 26, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz