[AccessD] Calling ADO without having to roll out five hundred newmdbs

ASP Interface.  IE should already be installed on the end users machines.
An Access .mdb on the IIS server itself is almost as good as a true SQL
Server, except the .mdb is faster (cause of less overhead), but it does have
the size limit, and no native transaction logs.

Drew

-----Original Message-----
From: Gustav Brock [mailto:Gustav at cactus.dk]
Sent: Wednesday, January 19, 2005 11:21 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Calling ADO without having to roll out five
hundred newmdbs


Hi Mark

Next step would be how to use Access without installing it on the
users' machines.
This list will be all ears!!

Well, I guess you have two options: Running a Terminal Service (oops,
did you say goodbye to your budget for the next three years?) or using
DCom - sending data to some "remote" machines running some apps for you
which will return massaged data to the user, much like a web service
today. 
If I recall correctly, Shamil was involved in a distributed POS system
using Dcom.

/gustav

>>> marklbreen at gmail.com 19-01-2005 17:17:25 >>>

..  I does not eliminate the
need to add the reference, but what it does suggest is that we should
not have to actually install ADO, which is what we were trying to
avoid.

> > We would like to use ADO for some stored procedures to avail of
output
> > parameters, but it is not desirable to have to reference ADO on
five
> > hundred PC's.  Especially with different versions of the OS
throughout
> > the company.
> >
> > Is there a way that I can call this ADO, from a central database
and
> > pass the results back to the clients that are located throughout
the
> > company?  Maybe MDA's?  I know that if I use MDA's that I will have
to
> > reference them, but that might not be too bad because at least I
can
> > control the version.  But that MDA will need the ADO reference.
> >
> > I have not really done any COM / DCOM work, but maybe some of you
have
> > and can think of a solution to this,
> >
> > The alternative is to try to rev the access db with new references
to ado.

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com