Mr. Kallal & Mr. Fenton: What did I do wrong?

[Vladimír Cvajniga]

Thank you, Tom.

In that case I think I can say: I always create my own unbound Switchboard
so that I'm sure I don't have to connect to any BE MDB when I open the
Switchboard (main form).

Vlado

 

[Tom Wickerath]

Hi Vlado,

Okay, so when you open your front-end application normally (ie. *not*
holding down the shift key), do you see a locking database file (*.ldb)
created for the back-end .mdb file? If so, you have a persistent connection.
If not, then you don't.

Note: Best to test by having the BE on your local hard drive, or at a time
when you know that no other users have the database open.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[David W. Fenton]

You'd trap for the error and present a customized message, such as
"This report will be available shortly."

And so you have to add a workaround which isn't necessary if you
keep the Switchboard table in the front end.

I'm inclined to agree with you here, given that the VBA code
behind my unbound switchboard forms is in the front-end too (which
is the only place it really could be).

So you're arguing just for the fun of it? OK!

I disagree. You do gain an automatic persistent connection,
without having to do anything else, so there *is* something to be
gained. Sure, you may have to work around some issues, like
trapping for an error in the event a report is not yet available,
but that's certainly not insurmountable.

If you're going to have to write code to trap for putting the table
in the wrong place, then why not write code to create a persistent
connection with a table that *belongs* in the back end?

 

[David W. Fenton]

What I've already mentioned a few times: a persistent connection
without the need to do anything else.

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

As opposed to simply writing a couple of lines of code that create
the persistent connection.

Really, isn't:

Dim dbBackEnd As DAO.Database
Dim strBackEnd as String

strBackEnd = Mid(CurrentDb.TableDefs("MyTable").Connect, 11)
Set dbBackEnd = DBEngine.OpenDatabase(strBackEnd)

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

And besides, your persistent connection could disappear if the user
closes the Switchboard form. So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code to work around
problems created by using the Switchboard for something other than
its intended purpose.

But it also introduces problems because of a period of latency
between adding the items to the table and rolling out the front
end.

In my case, probalby not. I tend to be a late night owl, so in my
case, by the time I'm making that new FE available (and updating a
linked SI table [if I used one]) all other employees have long
since gone home. In any case, just trap for any errors in the FE,
and present a customized error message, such as "This report will
be available shortly". No big deal really.

I think it's silly to write error trapping code for something that
doesn't need it. You're using the Switchboard table for a different
purpose (maintaining the persistent connection) than for what it is
designed to do, and that causes you to put it in a place that leads
to workarounds to fix the problems caused by moving it to the back
end.

It's a very Microsoft approach, to make an incorrect decision on the
front end (e.g., the SDI in Office) and then to create an elaborate
workaround to fix the problem created by the bad decision in the
first place (i.e., change your OS to group the multiplying
application windows in the TaskBar).

 

[Tom Wickerath]

But it causes you to have to do *other* things, like making sure you

don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, ...

Is that *really* so difficult? C'mon.

and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

Only if you 1.) must be able to update the app. during normal business hours
and 2.) want to prevent any possible errors. Both of these are certainly
laudable goals, and, as I've already indicated, *if* I used a switchboard
with a bound table design [which I don't], I probably would just leave it in
the FE. The whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the Switchboard Items
table in the FE.

Really, isn't:

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

It might be easier, but I wouldn't necessarily advice doing so, if you want
to ensure that each user has true record-level locking. You're much easier
code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The Tools>Options... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

And besides, your persistent connection could disappear if the user
closes the Switchboard form.

My users aren't allowed to close the switchboard form without closing the
application.

So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code...

Yeah, the only code that I really need to write is DoCmd.Quit on the EXIT
button, after disabling the Control Box for the form. By the way, I also only
distribute in the compiled .mde form, with shift key disabled. Certainly it
is easy enough for a knowledgeable person to re-enable the shift key, but I
have not found this to even be an issue. For one thing, most of my users
wouldn't know where to find the FE application. It is in the
hidden-by-default folder:

C:\Documents and Settings\NTUserID\Application Data\AppName\AppName.mde

(That's a nice benefit of using the AutoFE Updater, by the way. It's very
easy to create this path if it is not already present, and copy the FE app.
to this folder, using Tony's tool).



Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

What I've already mentioned a few times: a persistent connection
without the need to do anything else.

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

As opposed to simply writing a couple of lines of code that create
the persistent connection.

Really, isn't:

Dim dbBackEnd As DAO.Database
Dim strBackEnd as String

strBackEnd = Mid(CurrentDb.TableDefs("MyTable").Connect, 11)
Set dbBackEnd = DBEngine.OpenDatabase(strBackEnd)

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

And besides, your persistent connection could disappear if the user
closes the Switchboard form. So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code to work around
problems created by using the Switchboard for something other than
its intended purpose.

But it also introduces problems because of a period of latency
between adding the items to the table and rolling out the front
end.

In my case, probalby not. I tend to be a late night owl, so in my
case, by the time I'm making that new FE available (and updating a
linked SI table [if I used one]) all other employees have long
since gone home. In any case, just trap for any errors in the FE,
and present a customized error message, such as "This report will
be available shortly". No big deal really.

I think it's silly to write error trapping code for something that
doesn't need it. You're using the Switchboard table for a different
purpose (maintaining the persistent connection) than for what it is
designed to do, and that causes you to put it in a place that leads
to workarounds to fix the problems caused by moving it to the back
end.

It's a very Microsoft approach, to make an incorrect decision on the
front end (e.g., the SDI in Office) and then to create an elaborate
workaround to fix the problem created by the bad decision in the
first place (i.e., change your OS to group the multiplying
application windows in the TaskBar).

 

[David W. Fenton]

Is that *really* so difficult? C'mon.

It's one more thing that can go wrong. Just yesterday I accidentally
killed a live file on a website because I forgot to rename the work
copy before uploading it. Is that so difficult to get right? Not at
all! But I'm human and I make mistakes. Why design your app in a
fashion that increases the number of things on which you can make
mistakes?

and you have to
write code for the case where somebody attempts to open the
report before they have the new front end.

Only if you 1.) must be able to update the app. during normal
business hours and 2.) want to prevent any possible errors. Both
of these are certainly laudable goals, and, as I've already
indicated, *if* I used a switchboard with a bound table design
[which I don't], I probably would just leave it in the FE. The
whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the
Switchboard Items table in the FE.

I don't think you've made a good case for it.

It might be easier, but I wouldn't necessarily advice doing so, if
you want to ensure that each user has true record-level locking.
You're much easier code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The Tools>Options... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

I didn't know that. Apparently, nobody recommending the persistent
connection in code knows it, either.

Of course, I don't give a rat's ass about row-level locking, myself.
I don't use it and don't think it really works. But maybe that's
because I've always been using methods that prevent it.

My users aren't allowed to close the switchboard form without
closing the application.


Yeah, the only code that I really need to write is DoCmd.Quit on
the EXIT button, after disabling the Control Box for the form.

Do you also trap for Ctrl-F4? To really prevent it from closing, you
have to set a flag in your real exit code that is checked in the
OnClose event. If your real exit code hasn't run, the flag is not
set, and you cancel the form's close. That's the only way to really
prevent a form from being closed.

 

[i_takeuti]

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, ...

Is that *really* so difficult? C'mon.

and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

Only if you 1.) must be able to update the app. during normal business
hours
and 2.) want to prevent any possible errors. Both of these are certainly
laudable goals, and, as I've already indicated, *if* I used a switchboard
with a bound table design [which I don't], I probably would just leave it
in
the FE. The whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the Switchboard
Items
table in the FE.

Really, isn't:

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

It might be easier, but I wouldn't necessarily advice doing so, if you
want
to ensure that each user has true record-level locking. You're much easier
code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The Tools>Options... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

And besides, your persistent connection could disappear if the user
closes the Switchboard form.

My users aren't allowed to close the switchboard form without closing the
application.

So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code...

Yeah, the only code that I really need to write is DoCmd.Quit on the EXIT
button, after disabling the Control Box for the form. By the way, I also
only
distribute in the compiled .mde form, with shift key disabled. Certainly
it
is easy enough for a knowledgeable person to re-enable the shift key, but
I
have not found this to even be an issue. For one thing, most of my users
wouldn't know where to find the FE application. It is in the
hidden-by-default folder:

C:\Documents and Settings\NTUserID\Application Data\AppName\AppName.mde

(That's a nice benefit of using the AutoFE Updater, by the way. It's very
easy to create this path if it is not already present, and copy the FE
app.
to this folder, using Tony's tool).



Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

What can possibly be gained in terms of Switchboard functionality
by putting the Switchboard table in the back end?

What I've already mentioned a few times: a persistent connection
without the need to do anything else.

But it causes you to have to do *other* things, like making sure you
don't add the value in the production back end Switchboard table
until you have the front end ready to distribute, and you have to
write code for the case where somebody attempts to open the report
before they have the new front end.

As opposed to simply writing a couple of lines of code that create
the persistent connection.

Really, isn't:

Dim dbBackEnd As DAO.Database
Dim strBackEnd as String

strBackEnd = Mid(CurrentDb.TableDefs("MyTable").Connect, 11)
Set dbBackEnd = DBEngine.OpenDatabase(strBackEnd)

much easier than error catching code for the report and the planning
needed to worry about coordinating distributing the new front end
with entering the new data in the back end Switchboard table?

And besides, your persistent connection could disappear if the user
closes the Switchboard form. So, you'd have to write code that
prevents the Switchboard from being closed except by the EXIT button
for the application, so you've added still more code to work around
problems created by using the Switchboard for something other than
its intended purpose.

But it also introduces problems because of a period of latency
between adding the items to the table and rolling out the front
end.

In my case, probalby not. I tend to be a late night owl, so in my
case, by the time I'm making that new FE available (and updating a
linked SI table [if I used one]) all other employees have long
since gone home. In any case, just trap for any errors in the FE,
and present a customized error message, such as "This report will
be available shortly". No big deal really.

I think it's silly to write error trapping code for something that
doesn't need it. You're using the Switchboard table for a different
purpose (maintaining the persistent connection) than for what it is
designed to do, and that causes you to put it in a place that leads
to workarounds to fix the problems caused by moving it to the back
end.

It's a very Microsoft approach, to make an incorrect decision on the
front end (e.g., the SDI in Office) and then to create an elaborate
workaround to fix the problem created by the bad decision in the
first place (i.e., change your OS to group the multiplying
application windows in the TaskBar).

 

[Vladimír Cvajniga]

Hello,

I'd like to thank all for their comments & help. I have finished simple
tests on my (very slow) home P2P.
BE MDB was A97 MDB.

1) In my case, persistent connection ALWAYS slows down performance. Could it
be due to Czech version af Access? Therefore I will not apply persistent
connection in any of my A97 projects.
2) Registry settings (http://support.microsoft.com/kb/150384/) significantly
speed up performance if BE MDB is already open.
3) In the whole, David Fenton's method (global db variable) seems to work as
expected but, in my case, it slows down performance as well. I'd recommend
some tests on Jet 4 and non-P2P network.

Vlado
=============================================
Important increase of performance are marked with an asterisk (*).

P2P:
- notebook Acer TravelMate 223X
- Windows XP Professional CZ SP2
- 256 MB RAM
- 10MBit LAN card
- MS Office 97 Professional CZ SP2

- desktop PC (noname):
- Windows XP Professional CZ SP2
- P4, 786 MB RAM
- 100MBit LAN card
- MS Office 2002 Professional CZ SP2
———————————————————————————————————————————————
- notebook Acer TravelMate 223X
- main database: KES_data.mdb
- table Karta: 36 records

c:\Dokumenty\_Moje
projekty\Kes\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
on desktop mapped as Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
———————————————————————————————————————————————
desktop:
db1.mdb with connection to KES_data.mdb on notebook

without persistent connection:
desktop tests, see Public Function test:
9,203125 seconds
9,203125 seconds
9,203125 seconds

persistent connection created on notebook:
db1.mdb with connection to KES_data.mdb (db1 open in Access 97):
desktop tests, see Public Function test:
- open table VZDY (1 record):
40,21875 seconds
40,14063 seconds
40,48438 seconds

- open table VZDYtmp (0 records):
40,32813 seconds
40,20313 seconds
40,23438 seconds

persistent connection created on notebook:
db variable (no table open), see modPersistent.fncPersistentOpen
40,21875 seconds
40,14063 seconds
40,25 seconds
—————————————————————————————————————————
desktop:
desktop project KES.mdb (A97 project converted to A2002): 44.3MB
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
desktop project startup
without persistent connection:
35,7 seconds
35,8 seconds
34,7 seconds

desktop project startup
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
persistent connection created on notebook:
db variable, see modPersistent.fncPersistentOpen
2 minutes 34,7 seconds
2 minutes 33,0 seconds
2 minutes 32,4 seconds
—————————————————————————————————————————
notebook, from db1.mdb, no persistent connection:
0,151001 seconds
0,1500244 seconds
0,1500244 seconds
—————————————————————————————————————————
—————————————————————————————————————————
—————————————————————————————————————————
After changes in notebook's registry.
See http://support.microsoft.com/kb/150384/

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Value Name: SharingViolationDelay
Data Type: REG_DWORD
Data: 0 (Default: 200)

Value Name: SharingViolationRetries
Data Type: REG_DWORD
Data: 0 (Default: 5)
.....................................................................................
desktop:
db1.mdb with connection to KES_data.mdb on notebook

without persistent connection:
desktop tests, see Public Function test:
9,84375 seconds
9,90625 seconds
9,78125 seconds

persistent connection created on notebook:
db1.mdb with connection to KES_data.mdb (db1 open in Access 97):
desktop tests, see Public Function test:
- open table VZDY (1 record):
21,04736 seconds *
21,09424 seconds *
21,18701 seconds *

- open table VZDYtmp (0 records):
21,26514 seconds *
21,20264 seconds *
21,39063 seconds *

persistent connection created on notebook:
db variable (no table open), see modPersistent.fncPersistentOpen
21,25 seconds *
21,14063 seconds *
21,0 seconds *
—————————————————————————————————————————
desktop:
desktop project KES.mdb (A97 project converted to A2002): 44.3MB
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
desktop project startup
without persistent connection:
34,6 seconds
35,2 seconds
35,7 seconds

desktop project startup
connected to Z:\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb
persistent connection created on notebook:
db variable, see modPersistent.fncPersistentOpen
1 minute 11,1 seconds *
1 minute 12,7 seconds *
1 minute 10,1 seconds *
—————————————————————————————————————————
notebook, from db1.mdb, no persistent connection:
0,1508789 seconds
0,1401367 seconds
0,1503906 seconds
—————————————————————————————————————————
—————————————————————————————————————————
—————————————————————————————————————————
Note:
All timings apply to "cached" data (ie. 2nd, 3rd, 4th, ..., data access).
—————————————————————————————————————————
Public Function test()
Dim PauseTime, Start, Finish, TotalTime, i, s

Start = Timer

For i = 1 To 10
Debug.Print DCount("*", "Karta")
DoEvents
Next i

Finish = Timer
TotalTime = Finish - Start
s = TotalTime & " seconds"
Debug.Print s
MsgBox "Total time: " & s

End Function
—————————————————————————————————————————
modPersistent
Option Compare Database
Option Explicit

Public db As Database

Public Function fncPersistentOpen()
Set db = DBEngine.OpenDatabase("c:\Dokumenty\_Moje
projekty\Kes\Databaze2002\97\CvicnaDatabazeZS\KES_data.mdb")
End Function

Public Function fncPersistentClose()
db.Close
Set db = Nothing
End Function

 

[Tom Wickerath]

Of course, I don't give a rat's ass about row-level locking, myself.

I don't use it and don't think it really works.

Interesting that you would make this statement, given your earlier statement
in the Persistanct connections thread to Tom Ellison, in which you wrote:

"On the contrary, it can be *very* useful in reducing concurrency. A
random Autonumber means that the data ends up randomly distributed,
so that updates are not as likely to collide on the same data page."

(Note: "it" being a reference to a surrogate key versus a natural key).

So, you indicate an advantage of using a surrogate key helps to avoid
collisions on the same data page, yet you don't give a R.A. about row level
locking?

But maybe that's because I've always been using methods that prevent it.

I suspect so.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

Is that *really* so difficult? C'mon.

It's one more thing that can go wrong. Just yesterday I accidentally
killed a live file on a website because I forgot to rename the work
copy before uploading it. Is that so difficult to get right? Not at
all! But I'm human and I make mistakes. Why design your app in a
fashion that increases the number of things on which you can make
mistakes?

and you have to
write code for the case where somebody attempts to open the
report before they have the new front end.

Only if you 1.) must be able to update the app. during normal
business hours and 2.) want to prevent any possible errors. Both
of these are certainly laudable goals, and, as I've already
indicated, *if* I used a switchboard with a bound table design
[which I don't], I probably would just leave it in the FE. The
whole point of this {rather fruitless} discussion is to simply
offer a counterpoint to the opinion that one *must* put the
Switchboard Items table in the FE.

I don't think you've made a good case for it.

It might be easier, but I wouldn't necessarily advice doing so, if
you want to ensure that each user has true record-level locking.
You're much easier code just resulted in page-level locking.

PRB: Jet 4.0 Row-Level Locking Is Not Available with DAO 3.60
http://support.microsoft.com/?id=306435

The Tools>Options... | Advanced tab setting "Open databases using
record-level locking" is a request, not a demand.

I didn't know that. Apparently, nobody recommending the persistent
connection in code knows it, either.

Of course, I don't give a rat's ass about row-level locking, myself.
I don't use it and don't think it really works. But maybe that's
because I've always been using methods that prevent it.

My users aren't allowed to close the switchboard form without
closing the application.


Yeah, the only code that I really need to write is DoCmd.Quit on
the EXIT button, after disabling the Control Box for the form.

Do you also trap for Ctrl-F4? To really prevent it from closing, you
have to set a flag in your real exit code that is checked in the
OnClose event. If your real exit code hasn't run, the flag is not
set, and you cancel the form's close. That's the only way to really
prevent a form from being closed.

 

[Tom Wickerath]

Do you also trap for Ctrl-F4?

Nope. I suppose if a user tries to close my switchboard doing this, they'll
end up with Access still running, but a blank window. They won't be able to
display the database window using F11, since I remove the option that allows
the use of special keys, and I disable the shift key trick. (Yes, I know, a
knowledgeable user can always re-enable the shift key).

I suppose I could add an Autokeys macro to re-direct this key sequence, but
so far, no one has ever mentioned it being a problem.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

 

[David W. Fenton]

Interesting that you would make this statement, given your earlier
statement in the Persistanct connections thread to Tom Ellison, in
which you wrote:

"On the contrary, it can be *very* useful in reducing concurrency.
A random Autonumber means that the data ends up randomly
distributed, so that updates are not as likely to collide on the
same data page."

That's very clearly a case where I'm not using record-level locking,
so I don't see the point. If I were using record-level locking, I
wouldn't be worrying about contention for the same data page, right?

(Note: "it" being a reference to a surrogate key versus a natural
key).

So, you indicate an advantage of using a surrogate key helps to
avoid collisions on the same data page, yet you don't give a R.A.
about row level locking?

Row-level locking is slower than page locking, so random autonumbers
would give both a performance advantage and a concurrency
improvement.

There is no inconsistency in the two positions at all.

I suspect so.

I don't think anybody disputes that record-level locking is slower
than page-level locking, no?

 

[David W. Fenton]

Nope. I suppose if a user tries to close my switchboard doing
this, they'll end up with Access still running, but a blank
window. They won't be able to display the database window using
F11, since I remove the option that allows the use of special
keys, and I disable the shift key trick. (Yes, I know, a
knowledgeable user can always re-enable the shift key).

I suppose I could add an Autokeys macro to re-direct this key
sequence, but so far, no one has ever mentioned it being a
problem.

But you could avoid having to do that by checking a Boolean CloseOK
flag in the Switchboard's OnClose event, and cancelling if it's not
been set TRUE. Then you'd set it to TRUE in the code behind the
button that closes your app. That way, all your code preventing the
closing of your switchboard form would be *in* the switchboard, not
partly in it and partly in an AutoKeys macro.

 

[Tom Wickerath]

True. That's a better way of accomplishing the same thing, and, come to think
of it, I have used that method one time before, a long time ago.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[David W. Fenton]

True. That's a better way of accomplishing the same thing, and,
come to think of it, I have used that method one time before, a
long time ago.

So, have I now successfully bludgeoned you into agreement on all
points?

 

[Larry Linson]

Unless I am mistaken, a peer-to-peer network has a limit on the number of
concurrent connections which is different than the number of concurrent
connections to a server in a client-server network. As far as I know, that
has to do with network, not the OS version.

If that is so... the five, or ten, or whatever limit of concurrent
connections could have a significant impact on performance -- thus my
statement that "may make any findings in the former not useful in predicting
performance in the latter". That is, if you are testing performance with a
large number of users, and only a handful of connections can concurrently be
open, it will affect response, because some will not be able to establish
the connections they need when they need them.

Please feel free to correct my understanding if it is wrong. {Not that I am
implying you are bashful, or anything, David. }

Larry Linson
Microsoft Access MVP

 

[David W. Fenton]

Unless I am mistaken, a peer-to-peer network has a limit on the
number of concurrent connections which is different than the
number of concurrent connections to a server in a client-server
network. As far as I know, that has to do with network, not the OS
version.

If you mean connections to top-level share, yes, there's a limit. At
one time it was 10, then it changed, and I think it then changed
back.

But that's the number of *workstations* that can connect, which is
not the same thing as the term "connections" in a database context.
You could, for instance, use up the available MSDE conncurrent
connections from one workstation, if you were sloppy in your
programming.

That said, I still don't see what this has to do with the usual
advice on setting up persistent connections and performance, nor
what it has to do with record-level locking.