Hello,
What are the pre-requisites / conditions for the ability to create
multiple connections to MS ACCESS database and what is the precedence of its
application? adModeShareDenyNone in the code, Exclusive checkbox in the ODBC
source, Tools->Options->Advanced->Shared in the Database Options, what else?
I have a problem when multiple connections could not be opened at the same
time from my code on one server but could be on another server. Also,
adModeShareDenyNone and adModeShareDenyExclusive work as expected in some
cases and don't work as expected in other cases. So my guess that it could be
an interaction of several settings / conditions in different places. Please,
let me know your considerations on the subject.
Examples: (this is just a relevant part of the code)
ConnString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="& MyPath
&";User Id=admin;Password=;"
conn.mode = 16 'adModeShareDenyNone -will let to open second connection
' conn.mode = 12 'adModeShareDenyExclusive -will not let to open second
connection
conn.open ConnString
conn1.open ConnString
This ASP code works on 1 server and 1 laptop, does not work on another server.
If I uncomment conn.mode = 12 (Exclusive) this code will correctly allow only
1 connection to open. From withing this code. But I have no problems opening
this database from the file system at the same time(?)
Also if I have a database open from the file system I have no problems
running my code if the Database option is Shared on my workstation but if I
open the database from the file system on the web server not a single
additional connection could be established from the code. This database has
Shared checked too. For some reason it works fine on another web server.
I would appreciate your input what settings and where should I use to allow
code create multiple connections to the Access database. You may also point
me to the appropriate forum for this issues.
Thanks in advance,
Yelena
--
Regards,
Yelena Varshal
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200606/1