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

Mark Breen marklbreen at gmail.com
Thu Jan 20 07:09:22 CST 2005


Hello Drew,

:)

Nice one, I agree with your analogy of IIS / Access and IE.  For a
small Client Server app, it is an option.

We decided to test, following you guys comments, the setting of the
ADO reference and testing 10-30 machines.  As per Steve's and others
reference to the knowledge base, ADO should already be installed so
there should be no difficulty referencing it.

My next concern (and I am not asking for help, just thinking out load)
is the versions of ADO that we will reference.  What happens if I
reference ADO version 2.6 for example, but the user has a later or
earlier version than the development machine?

Do I need to programatically enumerate the references and check for
"missing" and then programatically attempt to assign another version
of ADO?  Does not sound that pretty !

I am not too concerned about needing the latest version, all we are
doing is calling an Oracle stored procedure and accepting output
parameters (hence the need to ADO in the first place).

Thanks for any comments,

Mark





On Wed, 19 Jan 2005 14:13:07 -0600, DWUTKA at marlow.com <DWUTKA at marlow.com> wrote:
> 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
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



More information about the AccessD mailing list