Can a front end be shared by more than one user?
I have an access front end with no local tables (other than a couple look ups).
It uses a couple of linked SQL server tables and quite a bit SQL Server Pass through queries which have parameters passed to them at run time (i.e. order numbers, etc.)
I was planning on still giving every user their own copy of the front end, but then I read something (somewhere) that it may not be necessary, that something as simple as this could be shared?
I am thinking no, but wanted to ask the question here for more clarification.
The application detects the current windows username, and utilizes that to authenticate the user. In some passthroughs, the user name is passed as a parameter to pull only specific data for that user.
Having said that, my understanding is that this could not be used as a multi-user front end. Correct?
The reason for the question is that our IT group would rather have a single user link on our intranet that when clicked, runs the front end. I am thinking this will not work, and each user needs a copy of the front end either locally on their computer, or residing in their own personal network share folder.
It uses a couple of linked SQL server tables and quite a bit SQL Server Pass through queries which have parameters passed to them at run time (i.e. order numbers, etc.)
I was planning on still giving every user their own copy of the front end, but then I read something (somewhere) that it may not be necessary, that something as simple as this could be shared?
I am thinking no, but wanted to ask the question here for more clarification.
The application detects the current windows username, and utilizes that to authenticate the user. In some passthroughs, the user name is passed as a parameter to pull only specific data for that user.
Having said that, my understanding is that this could not be used as a multi-user front end. Correct?
The reason for the question is that our IT group would rather have a single user link on our intranet that when clicked, runs the front end. I am thinking this will not work, and each user needs a copy of the front end either locally on their computer, or residing in their own personal network share folder.
Dale Fye
It is not recommended. In a multi-user environment, each user should have their own front-end.
<IT group would rather have a single user link on our intranet that when clicked..>
If you are consistent in what folder you place your applications on user's machines, this can work.
eg: if all of your databases reside in a dbApplications folder on the Users' machines, the link would be:
C:\dbApplications\YourDB.a
If you are consistent in what folder you place your applications on user's machines, this can work.
eg: if all of your databases reside in a dbApplications folder on the Users' machines, the link would be:
C:\dbApplications\YourDB.a
I used Access as the database accessed by many users without problems.
A problem may occur with increasing number of users.
Access used together with a share works 100%.
A problem may occur with increasing number of users.
Access used together with a share works 100%.
Paradox,
If you are sharing a front-end you are asking for corruption and other problems. Each user in a multi-user environment should have their own copy of the front-end.
If you are sharing a front-end you are asking for corruption and other problems. Each user in a multi-user environment should have their own copy of the front-end.
<<I was planning on still giving every user their own copy of the front end, but then I read something (somewhere) that it may not be necessary, that something as simple as this could be shared?>>
Yes it can be shared. Most however feel it's better to give each user their own copy. Reasons?
1. Less corruption - I've never seen any hard evidence that sharing a FE increases the chance of corruption, but that is the general consensus.
2. Better performance - this is becoming less of an issue with networks getting faster, but it does seem silly to be sending everything over the wire when nothing in a FE changes.
3. Temp tables - Often, especially with SQL BE's, data needs to be pulled into a temp table and reported on for performance reasons, but when users share a FE, this becomes a problem and most developers don't plan for it
Jim.
Yes it can be shared. Most however feel it's better to give each user their own copy. Reasons?
1. Less corruption - I've never seen any hard evidence that sharing a FE increases the chance of corruption, but that is the general consensus.
2. Better performance - this is becoming less of an issue with networks getting faster, but it does seem silly to be sending everything over the wire when nothing in a FE changes.
3. Temp tables - Often, especially with SQL BE's, data needs to be pulled into a temp table and reported on for performance reasons, but when users share a FE, this becomes a problem and most developers don't plan for it
Jim.
> Yes it can be shared. Most however feel it's better to give each user their own copy. Reasons?
They don't know how to share a FE.
But Jim's three points are true.
However:
2. On a modern Gigabit LAN the performance increase by having a local copy of a modest FE like yours is hard to measure.
1. and 3. The simple method to prevent this is to mark the FE file itself as Read-Only. This will, by definition, eliminate any corruption, and temp data controlled by Access are forced to the user's local storage. Of course, if your app itself does create temp tables, these have to be placed in a separate temp database file.
We have used this method - both in-house and at clients - for years (since Access 2.0!) with zero issues.
/gustav
They don't know how to share a FE.
But Jim's three points are true.
However:
2. On a modern Gigabit LAN the performance increase by having a local copy of a modest FE like yours is hard to measure.
1. and 3. The simple method to prevent this is to mark the FE file itself as Read-Only. This will, by definition, eliminate any corruption, and temp data controlled by Access are forced to the user's local storage. Of course, if your app itself does create temp tables, these have to be placed in a separate temp database file.
We have used this method - both in-house and at clients - for years (since Access 2.0!) with zero issues.
/gustav
Gustav,
When you use this technique, I assume that you then use ADO or SQL queries that contain an IN clause (example below) to access the local temp tables?
SELECT * FROM tempTable IN 'C:\Windows\Temp\myAppTemp
When you use this technique, I assume that you then use ADO or SQL queries that contain an IN clause (example below) to access the local temp tables?
SELECT * FROM tempTable IN 'C:\Windows\Temp\myAppTemp
No, though it would work.
But relinking is, of course, not an option of a R-O FE. The admin must set the linking, then apply the R-O flag. This is the method we use.
/gustav
But relinking is, of course, not an option of a R-O FE. The admin must set the linking, then apply the R-O flag. This is the method we use.
/gustav
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Batch files work to...as well as VB6 "Launcher" programs.
Jim.
I used to use a shared FE--but I am awfully glad I got away from that.
Deployed local front ends are just a lot less hassle.
You've got an IT deparment--they may be able to publish the FE through AD/GPO/Intellimirror too
Deployed local front ends are just a lot less hassle.
You've got an IT deparment--they may be able to publish the FE through AD/GPO/Intellimirror too
> Batch files work to ..
Indeed:
. And it is much simpler just to copy the FE anytime the user logs into Windows. No version check, no bloat, no nothing.
/gustav
Indeed:
@echo off
echo Fetching Power Application ...
copy f:\applications\distribution\powerapp.mdb c:\applications\localapps. And it is much simpler just to copy the FE anytime the user logs into Windows. No version check, no bloat, no nothing.
/gustav
My users rarely if ever logoff.
And from time to time I can rev three, four, five times in a day
The front-end is also meaty--80 MB--so if EVERYBODY hits it when it's not needful there is lag.
We had Vista and SBS 2003. The copy was 45 seconds or so on gigabit backbone.
Vista left as soon as possible :0 but not nearly soon enough :(
Even with Win7 and SBS 2008 it's 12 to 15 seconds to pull a new frontend.
So it happens when I rev, or when the script can see that the user crashed the frontend on the last go around.
And from time to time I can rev three, four, five times in a day
The front-end is also meaty--80 MB--so if EVERYBODY hits it when it's not needful there is lag.
We had Vista and SBS 2003. The copy was 45 seconds or so on gigabit backbone.
Vista left as soon as possible :0 but not nearly soon enough :(
Even with Win7 and SBS 2008 it's 12 to 15 seconds to pull a new frontend.
So it happens when I rev, or when the script can see that the user crashed the frontend on the last go around.
> My users rarely if ever logoff.
Well, power is so expensive here that workstations are closed down during off-hours.
> And from time to time I can rev three, four, five times in a day
?!
/gustav
Well, power is so expensive here that workstations are closed down during off-hours.
> And from time to time I can rev three, four, five times in a day
?!
/gustav
<?!>
Lots of little changes.
'Can you add a phrase to a combo box and have it add some records'
'Can you change this report just a little'
Lots of little changes.
'Can you add a phrase to a combo box and have it add some records'
'Can you change this report just a little'
I don't think anyone has mentioned another reason not to share the FE. With SQL Server back-ends, there are advantages to modifying persistent passthrough queries. This won't work for a shared FE.
I mention this technique near the end of "Best of Both Worlds", a PowerPoint presentation on techniques for using Access as a client-server front-end to SQL Server databases.
http://www.JStreetTech.com/downloads
Cheers,
Armen
I mention this technique near the end of "Best of Both Worlds", a PowerPoint presentation on techniques for using Access as a client-server front-end to SQL Server databases.
http://www.JStreetTech.com/downloads
Cheers,
Armen
ASKER
Nick your code is interesting and I like the concept, but what triggers it? Where does this code reside?
They are vbscript files
Notepad files renamed from .txt to .vbs
Typically, I create shortcuts to them, and tweak the icon picture to be Access.
Copy the first snippet.
Paste it into notepad.
Save as Deploy.vbs
Copy the second snippet
Paste it into notepad
Save as CopyAndDeploy.vbs
My dev folder is m:/dev
My deploy folder is m:/deploy
The local FE location is c:\prod
The FE is TI_Prog.mdb
Some of the script is concerned with ensuring that the ancillary files are also in place
mousehook.dll
rapi.dll
RemoteCE.tlb
PhotoResize700O.exe
But these probably don't apply to you
Ver.txt needs to be in the deploy folder, start with 1.0.0.0 on a single line in the file
Copy and deploy increments the last digit
ver.txt gets copied down to the local FE locations
Modify as necessary
Notepad files renamed from .txt to .vbs
Typically, I create shortcuts to them, and tweak the icon picture to be Access.
Copy the first snippet.
Paste it into notepad.
Save as Deploy.vbs
Copy the second snippet
Paste it into notepad
Save as CopyAndDeploy.vbs
My dev folder is m:/dev
My deploy folder is m:/deploy
The local FE location is c:\prod
The FE is TI_Prog.mdb
Some of the script is concerned with ensuring that the ancillary files are also in place
mousehook.dll
rapi.dll
RemoteCE.tlb
PhotoResize700O.exe
But these probably don't apply to you
Ver.txt needs to be in the deploy folder, start with 1.0.0.0 on a single line in the file
Copy and deploy increments the last digit
ver.txt gets copied down to the local FE locations
Modify as necessary
ASKER
Will it work in mixed environments? (Access 2000, 2007,2010)
Being small enough I cheated and had 3, one for each version
Then I learned that
Set acApp=CreateObject("Access
is version agnostic
I copy and pasted from the original
Set acApp=CreateObject("Access
Take the .11 off and it should play
Then I learned that
Set acApp=CreateObject("Access
is version agnostic
I copy and pasted from the original
Set acApp=CreateObject("Access
Take the .11 off and it should play
ASKER
Follow up question posted below:
https://www.experts-exchange.com/questions/27323130/Need-some-additional-help-with-this-script-to-update-front-ends.html
https://www.experts-exchange.com/questions/27323130/Need-some-additional-help-with-this-script-to-update-front-ends.html