A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

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



 
 
Thread Tools Display Modes
  #51  
Old April 13th, 2007, 05:22 PM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Persistanct connections

Tom Wickerath AOS168b AT comcast DOT net wrote in
news
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."


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.

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


I suspect so.


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

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
  #52  
Old April 13th, 2007, 05:24 PM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Persistanct connections

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

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.


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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
  #53  
Old April 14th, 2007, 09:24 AM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default Persistanct connections

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/ex...tributors.html
__________________________________________

"David W. Fenton" wrote:

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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


  #54  
Old April 14th, 2007, 08:27 PM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Persistanct connections

Tom Wickerath AOS168b AT comcast DOT net wrote in
:

"David W. Fenton" wrote:

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.


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?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
  #55  
Old April 14th, 2007, 11:56 PM posted to microsoft.public.access
Larry Linson
external usenet poster
 
Posts: 3,112
Default Persistanct connections

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" wrote in message
. 1...
"Larry Linson" wrote in
:

The difference in the limit of number of connections between
machines on a P2P versus a server may make any findings in the
former not useful in predicting performance in the latter.

Yes, you can use linked tables between machines in a P2P. But,
most of the performance information and suggestions you see here
and in references applies to a server on a LAN.


Exactly what differences do you adduce between a Windows workstation
acting as a server and a Windows server? What parameters are
different between the two that would cause the issues we are
attempting to resolve with the persistent connection?

Remember, the server and workstation versions of any version of
Windows are binary identical and the only difference is
configuration settings.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/



  #56  
Old April 15th, 2007, 02:34 PM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Persistanct connections

"Larry Linson" wrote in
:

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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 02:16 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.