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. |
|
|
Thread Tools | Display Modes |
#51
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|