"ralph" wrote:

>
>
> "Sandy" wrote:
>
> > Hello -
> >
> > Can an application that will be supporting 225 concurrent users use the
> > mechanical settings using the ADODC control as opposed to writing code?
> >
> > It seems to me that with a number of tables, one may run into a problem of
> > multiple connections for one user multiplied by the concurrent users and have
> > a large problem.  Is this the true? 
> >
> > --
> > Sandy
>
> No.
>
> Well maybe. <g>
>
> If you create one ADO.Connection object for each application, you can assign
> that to your ADODCs. ADO uses connection pooling and as VB applications are
> essentially single-threaded, with judicious use of Opening and Closing
> connections - you are not tied to one ADODC - one connection. Also ADO will
> close inactive connections in about 2 seconds. So you will always have
> something less than the number of controls.
>
> However, whenever you are designing a database application and there is a
> finite limit on the number of open connections - "multiple connections for
> one user multiplied by the concurrent users" - can always present an
> opportunity for problems. The number of controls is the least of them.
>
> There are other alternative strategies you might want to employ. - It all
> depends on your problem domain (the wire, the rdbms, frequency, concurrancy,
> &etc.)
>
> -ralph
>
>
>

"Sandy" <Sa***@discussions.microsoft.com> wrote in message
news:504CB3B7-6AD5-4BB8-A189-38A3DDBABA01@microsoft.com...
> Thanks for your response, Ralph!
>
> >However, whenever you are designing a database application and there is a
> >finite limit on the number of open connections - "multiple connections
for
> >one user multiplied by the concurrent users" - can always present an
> >opportunity for problems. The number of controls is the least of them.
>
> I know the number of controls is the least of the problems, but every
ADODC
> has its own connection string and is opening a separate connection, isn't
it?
>
> >There are other alternative strategies you might want to employ.
> Which ones would you suggest?  Do you have any samples?
> --
> Sandy
>
>

"Ralph" wrote:

>
> "Sandy" <Sa***@discussions.microsoft.com> wrote in message
> news:504CB3B7-6AD5-4BB8-A189-38A3DDBABA01@microsoft.com...
> > Thanks for your response, Ralph!
> >
> > >However, whenever you are designing a database application and there is a
> > >finite limit on the number of open connections - "multiple connections
> for
> > >one user multiplied by the concurrent users" - can always present an
> > >opportunity for problems. The number of controls is the least of them.
> >
> > I know the number of controls is the least of the problems, but every
> ADODC
> > has its own connection string and is opening a separate connection, isn't
> it?
> >
> > >There are other alternative strategies you might want to employ.
> > Which ones would you suggest?  Do you have any samples?
> > --
> > Sandy
> >
> >
> <snipped>
>
> No. Each ADODC doesn't necessarily open and keep open a "connection". In
> usual practice each will share a 'connection' in common.
>
> There is a difference between an ADO.Connection object and the actual number
> of "Connections" managed by an OLE DB provider used by that object. That is
> why there isn't a one-to-one match up.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev00/html/Rob.asp
>
> Actual behavior will depend on how you have designed your application, the
> providers used, and the source.
>
> Get a hold of Bill Vaughn's book: "ADO Examples and Best Practices", Apress.
>
> Note: Many programmers eschew any of the Data Environment controls or
> designers. To easily experiment with alternatives to the using the ADODC try
> out the "Data Form Wizard" (Project...Add... Forms...) and chose "ADO Code"
> or "Class" Binding Types. However, no matter what binding type you chose -
> 'Connection' issues are the same.
>
> -ralph
>
>
>