No. Fill opens the connection automatically and closes it afterwards.
However, if for any reason the connection has already been opened, Fill does
not change the connection state.
See >>>
--
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit
www.hitchhikerguides.net to get more information on my latest books:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition) and
Hitchhiker's Guide to SQL Server 2005 Compact Edition
-----------------------------------------------------------------------------------------------------------------------
fniles said:
Thank you.
I am sorry I am still not clear on how to call the Fill method without
opening the connection manually before hand.
Do you have to open the connection sometime before hand ?
If for example application A and B uses the same database (either Access
or
SQL Server). If maximum connection pooling is 100, each application will
get 100 maximum connection pooling, is this correct ?
Connection pools are maintained on a process/application basis. Pools are
not shared between processes. Again, this assumes that the JET OLE DB
provider implements pooling. While I suspect it does, the issue has never
come up because JET when used in a Windows Forms application does not need a
pool unless you have implemented the application incorrectly.
I notice when the application uses an Access db on my machine (where no
other application access that database) my application does not reach the
maximum pool connection as fast as when I use an Access db on our server
(where many other applications access that database).
Is this because even though my application say has maximum of 100
connections, because other applications access the same database, there
may
not be connection available ?
In a JET architecture where Windows Forms applications are opening the
database, each client/user gets its own copy of JET to manage the shared
file. Each client has its own pool and are not sharing any other
applications' pool. Just because your application opens more than one
connection, it does not impact the other applications' pool. It DOES impact
the performance of the application as each JET engine must perform physical
IO over the LAN to share the database file. This means if your (or any)
application opens a lot of connections to the datatabase, this puts an
enormous load on the system and the ability to share the data.
Remember that JET was designed to support a few users with light load. It
breaks down quickly when stressed (as you have discovered).
Again, this is all covered in my earlier books. Considering that MS
encourages developers to get off of JET for more suitable DBMS engines, I
suggest you follow their suggestions (and mine).