I would think that using ms-access as com object on a server to accept
requests is so bad of a idea, and so bad as a design as to ask what are you
folks really trying to do?
None of the of the office appcltions from Word to ms-access should be used
as a automation object on the SERVER side. There are many warnings about
doing this in the KB.
However, it is just common sense that the office applications are NOT server
side automation objects, and I can't EVER imagine that you would get a
degree of reliability to make the whole process work.
Any reason why a com object is not being written in VB or c++? You could
certainly have multiple instances of the same form, and you also have
multiple instances of a class objects you create in ms-access. However, this
still means that using ms-access to accept multiple socket connections
sounds like the wrong kind of hammer for the nail you are trying to hit.
You can certainly use JET with VB or c++ to read/write data to the mdb file
format, but I would gasp at the concept of running ms-access as a automation
object on the server side...yikes!
I would think if someone does come up with a solution, I would still avoid
it. I just can't see any type of reliability in using a application like
ms-access on the server side. You will in a sense have to write your own
event loop, and span a new instance of the form...that is got to be really
messy.
I suppose we are kind of asking how does a application normally accept
multiple connections and deal with this problem. I don't even think the
winsock control is up to this task.
You could certainly try using JET along with VB or C++, but trying to do so
with a ms-access form...hum...I am not sold!
