Hi JohnK
You seem to be just the right kind of person to ask my question too.
Let me give you a bit of background first though.
I started developing the system about 6 months ago. I am an old hand at assembler language, and a bit risky with C,C++.
How ever ever since I started with VB6 I have found that it fits like a good glove. I like the OO approach. Black boxes with very clearly defined in's and out's. It fitted in very nicely where I left off with my assembler.
I became very bored with my firmware, so I got the oppotunity to develop an access control system with VB6. The first thing that I discovered was interfaces. I love them. The next thing I dicovered was COM+. I love it.
I felt very blessed, because I would be developing a system from the ground up. I developed the access control hardware, the firmware that ran on the controllers, the serial comms protocol between the PC and the controllers, and the first thing I developed on the PC was a DLL that took complete control of all the serial communications requirements of the access controllers.
The next step for me to develop was a system whereby a central server would be able to control a number of remote servers each of would be in control of a COM port. I first tried COM+ to do this, but I found that the whole design of COM+ does not lead to an object that must always stay active (the comms DLL). I then resorted to RPC to talk to the remote servers, with the remote servers sending back running logs with MSMQ. This works very well. I use RPC for the functions for which I need direct feed back from the remote server. For things like card down loads, or configutaion settings I use MSMQ to send the data from the Master Server to these remote servers. Each of the remote servers strores very specific control information for the controllers in registry, so that the actual running of the controllers remains the responsibilty of the remote servers. I will from now on call these remote servers "Polling Servers" which is exactly what they do.
The next step was for me to develop a central database system for recording details such as card numbers, user's names, access profiles and such like. The datbase would also need to log all "events" received from the controllers. I started developing with MSAccess using ADO but quickly made the jump to SQL. I found that the only thing that I had to change was the connection string, so this went absolutely smoothly. I developed a DLL that does literaly all the database work and exposes methods and properties for all its functionality. A nice black box.
The next problem I faced was the fact that the eventual client apps could be running on any PC on the LAN. These client apps, depending on there functions need feed back from the controllers. An example would be as to whether a certain person was in the building or not. This same client app could be running on multiple PCs on the LAN so I somehow needed to broadcast this information to these PC. However to broadcast all the controller events on the network would literrally flood the network. So what I developed was a system whereby a client app would subscribe to the Master server for specific events. What happens now is that when a specific event comes from the controllers, via the Polling servers, via MSMQ, the Master Server then does a RPC call to each of the subscribed hosts. The method called on the ActiveX EXE on the host machine then raises a standard VB event. Any client apps that have this class set with events receives the "event from the controller".
The next step I needed to develop was that any PC on the LAN running the appropriate client app could start or stop any controller or Polling Server anywhere on the system. They would also be able to initiates card down loads etc. Here is where COM+ comes in. The client app tells the MAster Server that the Controller with this GUID must stop. The master server then determines to which Polling Server the command must go. The command for the controller then gets put on to the MSMQ queue for the specific Polling Server.
As I said this has taken me just under 6 months to develop, but I mean an 18 hour a day 6 months.
To break down the system into tiers.
Level one - The user interface and client apps.
Level two - The master server level where all redirecting takes place whether it be to or from client apps, or to and from Polling Servers. This system consists of about 4 of 5 DLLs and one ActiveX EXE
Level three - I have to divide this level into two parts.
The first part would have to be the database wrapper DLL.
The second part is the Polling Server. This in itself consists of one ActiveX EXE and three DLLs.
Level four is once again divided into two parts. The first part is the database itself. The second part is the actual controllers themselves, which have their own databases.
It took me quite a while to be able to fit the whole system into these tiers. But now that I have it seems to fit nicely.
OK, now that I have finished boasting of my exploits, let me ask you the question I need to ask.
It has got to do with ADO record sets and interfaces.
I use interfaces extensively, and have written IDL code for them and they work well. The client apps all connect to the Master Server via DCOM ala COM+.
The only problem with interfaces that I have is when I am running a client app on remote machine. I cannot use record sets in these interfaces. The only way I can send recordset to and from a client is if these methods or properties are in the VB default interface. The reason for this is because I have to use late binding (DIM XXX as Object) to get access to the interfaces with record set's methods and propeties. Now this goes past the whole method of getting access to my interfaces. These interfaces have to be declared specifically. (DIM XXX as SomeInterface) and then I set XXX to the default interface. I am sure that you must know what I am writing about. Is there any way to get record sets to work on my own interfaces.
The reason I would like to do this, is for compatibility issues. The whole reason I have written the interfaces, is that client apps rely on these interfaces for compatibility via the Type libraries. The clients all connect to the VB default interfaces with CreateObject("Prog.ID"
which means they do not care about the class IDs on my server app. But now because of these record set problems the default VB interfaces also have to have methods in them to get and set the record sets. It seems to defeat the whole reason why I use intefaces.
Do you have any solutions for me.
The Big Viking
