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 |
#31
|
|||
|
|||
Persistanct connections
"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/ |
#32
|
|||
|
|||
Persistanct connections
If the switchboard table is in the back end, users will see the
choice to print the report, but won't be able to do so, as they don't have the updated copy of the front end. My users *would* have immediate access to the new report, because I use Tony Toews AutoFE updater. As soon as they double-clicked on their desktop icon to start the application, a new copy would be downloaded. So, one can have the Switchboard Items table in the BE database, and it does not have to be a problem. Whether or not it *belongs* in the FE is certainly debateable, but that's an academic debate for me, which I'm really not interested in pursuing, since I only use unbound switchboard forms. 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: From A2K on, the Switchboard wizard writes ADO code, so it can't possibly be using SEEK. One reason I tend to avoid the wizard generated switchboard. I do believe it breaks for some reason when you move it to the back end. But the switchboard table doesn't *belong* in the back end. Take this scenario: 1. you create a new report in your development copy. 2. you add it to the switchboard. If the switchboard table is in the back end, users will see the choice to print the report, but won't be able to do so, as they don't have the updated copy of the front end. For that reason, the switchboard belongs in the front end because it is connected to the version of the front end you are using, not to the data. It is a user interface object and the data store for it belongs with the UI. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#33
|
|||
|
|||
Persistanct connections
Answered he
http://www.microsoft.com/office/comm...8-03e4c228be96 For instance, you create a report in your development front end and add a menu choice to the switchboard. If I used a bound switchboard (which I don't), I would modify the Switchboard Items table first in a dev. copy of the BE. Once I was satisfied all was well, then I would roll out the new FE, with an updated copy of the Switchboard Items table in the production BE. Or, perhaps I would do as you suggest, and just leave the Switchboard Items table in the FE. I use unbound switchboard forms exclusively, so I've never really pondered this question in depth. But, it certainly is possible to keep the Switchboard Items table in the BE, and if you do so, it will serve nicely to maintain the persistent connection without any more fuss. Sure, there may be slight obstacles that one needs to consider (such as not updating the production copy of the Switchboard Items table without forcing an update of the FE), but those issues are easy to work around. Even if one maintains the Switchboard Items table in the FE, there certainly is no guarantee of continued functionality working if the developer makes changes to the BE database. In my mind, it's "six-one-half-a-dozen-the-other". 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: What about a new version? How do you coordinate adding a new menu choice to the switchboard with the creation of new features in the front end? For instance, you create a report in your development front end and add a menu choice to the switchboard. If the switchboard table is in the back end, then all your users will now see the new menu choice but won't have the report in the front ends yet. The switchboard is part of the user interface. Its data stroe belongs in the front end because it applies to user interface functionality in the front end. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#34
|
|||
|
|||
Persistanct connections
Hi John,
I have just finished testing one more variation: this time using Access 97. The bound switchboard form works fine with a linked Switchboard Items table in this version too. In addition, I searched the code module behind the Switchboard form for the word "Seek" in all four tests, and I have found no occurances. Which version did you experience this problem in? Was it Access 95 or earlier? Tom Wickerath Microsoft Access MVP https://mvp.support.microsoft.com/profile/Tom http://www.access.qbuilt.com/html/ex...tributors.html __________________________________________ "Tom Wickerath" wrote: Hi John, I just finished testing three new switchboards, created using Access 2000, 2002 and 2003. In each case, the Switchboard Items table was a linked table. It works fine in all three versions. Tom Wickerath Microsoft Access MVP https://mvp.support.microsoft.com/profile/Tom http://www.access.qbuilt.com/html/ex...tributors.html __________________________________________ "John W. Vinson" wrote: On Sun, 8 Apr 2007 17:06:04 -0700, Tom Wickerath AOS168b AT comcast DOT net wrote: Yes, the Switchboard Manager wizard does create a local table. However, this table is moved to the back-end file as soon as you use the database splitter wizard. In my experience, the Switchboard then immediately stops working (because the switchboard wizard code uses Seek and expects the table to be local). Only if you re-import the Switchboard table into the frontend can you use the switchboard! One reason I tend to avoid the wizard generated switchboard. John W. Vinson [MVP] |
#35
|
|||
|
|||
Persistanct connections
Tom Wickerath AOS168b AT comcast DOT net wrote in
: If the switchboard table is in the back end, users will see the choice to print the report, but won't be able to do so, as they don't have the updated copy of the front end. My users *would* have immediate access to the new report, because I use Tony Toews AutoFE updater. As soon as they double-clicked on their desktop icon to start the application, a new copy would be downloaded. But what if someone has the front end open, you add the menu item to the Switchboard, and they go to the reports menu on it. They'll see the report before they've got it in their front end. So, one can have the Switchboard Items table in the BE database, and it does not have to be a problem. Whether or not it *belongs* in the FE is certainly debateable, but that's an academic debate for me, which I'm really not interested in pursuing, since I only use unbound switchboard forms. I think it's obvious that the UI to give access to the application's functions is by definition a UI object and all its components should be kept in synch with the front end. What do you gain by putting the table in the back end? Nothing -- if it's in the front end, they're getting the data when they need it. If you're using Tony's updater, then they would be getting it at exactly the same time as they'd have access to report otherwise, and you don't have any interval whatsoever when a user could be offered the opportunity to run something that's not actually there yet. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#36
|
|||
|
|||
Persistanct connections
Tom Wickerath AOS168b AT comcast DOT net wrote in
: For instance, you create a report in your development front end and add a menu choice to the switchboard. If I used a bound switchboard (which I don't), I would modify the Switchboard Items table first in a dev. copy of the BE. Once I was satisfied all was well, then I would roll out the new FE, with an updated copy of the Switchboard Items table in the production BE. Or, perhaps I would do as you suggest, and just leave the Switchboard Items table in the FE. What can possibly be gained in terms of Switchboard functionality by putting the Switchboard table in the back end? I use unbound switchboard forms exclusively, so I've never really pondered this question in depth. Well, I use bound ones and I *have* pondered the question. But, it certainly is possible to keep the Switchboard Items table in the BE, and if you do so, it will serve nicely to maintain the persistent connection without any more fuss. But it also introduces problems because of a period of latency between adding the items to the table and rolling out the front end. That latency can never be zero when you store the Switchboard table in the back end. It will *always* be zero when the table is in the front end. Other tables are always available for the persistent link. (I don't use persistent links, BTW. I do use global db variables, but those point to the front end, so they don't server the purpose of the persistent connection. I've never seen a performance improvement when I implemented a persistent connection on an app that had performance issues) Sure, there may be slight obstacles that one needs to consider (such as not updating the production copy of the Switchboard Items table without forcing an update of the FE), but those issues are easy to work around. And if you keep the SWitchboard in the front end, then there is nothing to work around. Even if one maintains the Switchboard Items table in the FE, there certainly is no guarantee of continued functionality working if the developer makes changes to the BE database. In my mind, it's "six-one-half-a-dozen-the-other". Huh? What changes to the BE? The Switchboard table is not changed structural -- only the data changes. If your app fails with a change in the *data* then you have far worse problems than choosing where to put the Switchboard table! -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#37
|
|||
|
|||
Persistanct connections
In English, is Switchboard the same as the Dashboard (in terms of MS
Access)? Vlado "David W. Fenton" píse v diskusním príspevku . 1... Tom Wickerath AOS168b AT comcast DOT net wrote in : For instance, you create a report in your development front end and add a menu choice to the switchboard. If I used a bound switchboard (which I don't), I would modify the Switchboard Items table first in a dev. copy of the BE. Once I was satisfied all was well, then I would roll out the new FE, with an updated copy of the Switchboard Items table in the production BE. Or, perhaps I would do as you suggest, and just leave the Switchboard Items table in the FE. What can possibly be gained in terms of Switchboard functionality by putting the Switchboard table in the back end? I use unbound switchboard forms exclusively, so I've never really pondered this question in depth. Well, I use bound ones and I *have* pondered the question. But, it certainly is possible to keep the Switchboard Items table in the BE, and if you do so, it will serve nicely to maintain the persistent connection without any more fuss. But it also introduces problems because of a period of latency between adding the items to the table and rolling out the front end. That latency can never be zero when you store the Switchboard table in the back end. It will *always* be zero when the table is in the front end. Other tables are always available for the persistent link. (I don't use persistent links, BTW. I do use global db variables, but those point to the front end, so they don't server the purpose of the persistent connection. I've never seen a performance improvement when I implemented a persistent connection on an app that had performance issues) Sure, there may be slight obstacles that one needs to consider (such as not updating the production copy of the Switchboard Items table without forcing an update of the FE), but those issues are easy to work around. And if you keep the SWitchboard in the front end, then there is nothing to work around. Even if one maintains the Switchboard Items table in the FE, there certainly is no guarantee of continued functionality working if the developer makes changes to the BE database. In my mind, it's "six-one-half-a-dozen-the-other". Huh? What changes to the BE? The Switchboard table is not changed structural -- only the data changes. If your app fails with a change in the *data* then you have far worse problems than choosing where to put the Switchboard table! -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#38
|
|||
|
|||
Persistanct connections
But what if someone has the front end open, you add the menu item to
the Switchboard, and they go to the reports menu on it. They'll see the report before they've got it in their front end. You'd trap for the error and present a customized message, such as "This report will be available shortly." I think it's obvious that the UI to give access to the application's functions is by definition a UI object and all its components should be kept in synch with 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). What do you gain by putting the table in the back end? Nothing -- if it's ... 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. 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: Tom Wickerath AOS168b AT comcast DOT net wrote in : If the switchboard table is in the back end, users will see the choice to print the report, but won't be able to do so, as they don't have the updated copy of the front end. My users *would* have immediate access to the new report, because I use Tony Toews AutoFE updater. As soon as they double-clicked on their desktop icon to start the application, a new copy would be downloaded. But what if someone has the front end open, you add the menu item to the Switchboard, and they go to the reports menu on it. They'll see the report before they've got it in their front end. So, one can have the Switchboard Items table in the BE database, and it does not have to be a problem. Whether or not it *belongs* in the FE is certainly debateable, but that's an academic debate for me, which I'm really not interested in pursuing, since I only use unbound switchboard forms. I think it's obvious that the UI to give access to the application's functions is by definition a UI object and all its components should be kept in synch with the front end. What do you gain by putting the table in the back end? Nothing -- if it's in the front end, they're getting the data when they need it. If you're using Tony's updater, then they would be getting it at exactly the same time as they'd have access to report otherwise, and you don't have any interval whatsoever when a user could be offered the opportunity to run something that's not actually there yet. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#39
|
|||
|
|||
Persistanct connections
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 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. Other tables are always available for the persistent link. True....I won't argue that. Huh? What changes to the BE? I'm talking mostly about the very early stages of development, where a customer want to be able to see the progress, but the requirements are still being decided. So, for example, you might be told all of a sudden "we thought we'd only need to record one comment per record, but we really need many". So, you yank your comments field out of a table and put it into a child table, related 1:M. So, the situation I had in mind is where the requirements are still quite fluid. The Switchboard table is not changed structural -- only the data changes. I understand that. 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: Tom Wickerath AOS168b AT comcast DOT net wrote in : For instance, you create a report in your development front end and add a menu choice to the switchboard. If I used a bound switchboard (which I don't), I would modify the Switchboard Items table first in a dev. copy of the BE. Once I was satisfied all was well, then I would roll out the new FE, with an updated copy of the Switchboard Items table in the production BE. Or, perhaps I would do as you suggest, and just leave the Switchboard Items table in the FE. What can possibly be gained in terms of Switchboard functionality by putting the Switchboard table in the back end? I use unbound switchboard forms exclusively, so I've never really pondered this question in depth. Well, I use bound ones and I *have* pondered the question. But, it certainly is possible to keep the Switchboard Items table in the BE, and if you do so, it will serve nicely to maintain the persistent connection without any more fuss. But it also introduces problems because of a period of latency between adding the items to the table and rolling out the front end. That latency can never be zero when you store the Switchboard table in the back end. It will *always* be zero when the table is in the front end. Other tables are always available for the persistent link. (I don't use persistent links, BTW. I do use global db variables, but those point to the front end, so they don't server the purpose of the persistent connection. I've never seen a performance improvement when I implemented a persistent connection on an app that had performance issues) Sure, there may be slight obstacles that one needs to consider (such as not updating the production copy of the Switchboard Items table without forcing an update of the FE), but those issues are easy to work around. And if you keep the SWitchboard in the front end, then there is nothing to work around. Even if one maintains the Switchboard Items table in the FE, there certainly is no guarantee of continued functionality working if the developer makes changes to the BE database. In my mind, it's "six-one-half-a-dozen-the-other". Huh? What changes to the BE? The Switchboard table is not changed structural -- only the data changes. If your app fails with a change in the *data* then you have far worse problems than choosing where to put the Switchboard table! -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#40
|
|||
|
|||
Persistanct connections
Hi VladimĂ*r,
Yes, I think so. Tom Wickerath Microsoft Access MVP https://mvp.support.microsoft.com/profile/Tom http://www.access.qbuilt.com/html/ex...tributors.html __________________________________________ "VladimĂ*r Cvajniga" wrote: In English, is Switchboard the same as the Dashboard (in terms of MS Access)? Vlado |
Thread Tools | |
Display Modes | |
|
|