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
  #31  
Old April 9th, 2007, 06:24 PM posted to microsoft.public.access
David W. Fenton
external usenet poster
 
Posts: 3,373
Default 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  
Old April 9th, 2007, 09:12 PM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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  
Old April 9th, 2007, 09:20 PM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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  
Old April 9th, 2007, 09:28 PM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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  
Old April 10th, 2007, 07:26 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
:

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  
Old April 10th, 2007, 07:31 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
:

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  
Old April 10th, 2007, 08:59 PM posted to microsoft.public.access
Vladimír Cvajniga[_2_]
external usenet poster
 
Posts: 82
Default 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  
Old April 11th, 2007, 06:32 AM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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  
Old April 11th, 2007, 06:46 AM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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  
Old April 11th, 2007, 06:48 AM posted to microsoft.public.access
Tom Wickerath
external usenet poster
 
Posts: 3,914
Default 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

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 04:06 PM.


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