UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Front End Deployment Of Split Database In A Small Environment, Access 2016    
 
   
jmark@stayintouc...
post Apr 24 2019, 06:27 PM
Post#1



Posts: 1
Joined: 24-April 19



I have 15 users that use their own copies of the Front End of a single, small (30M) database. Every time I make a change to the FE, which is frequent, I have to push out the new FE to the desktops of all 15 users. All users use the same kind of PCs, the same Windows 10, and the same Access 2019. The BE is hosted on a shared network folder that all users have full access to. The question is: is there any significant reason that I cant have just ONE FE located on the Shared Network and have shortcuts to this single FE located on each users' desktop so that they all basically are opening the same FE over the network? This would make my updating infinitely easier. Can anyone shed any experienced light on this? thanks in advance!
Go to the top of the page
 
GroverParkGeorge
post Apr 24 2019, 07:09 PM
Post#2


UA Admin
Posts: 35,902
Joined: 20-June 02
From: Newcastle, WA


Welcome to UtterAccess.

Sharing a single FE has been associated with corruption. Seasoned Access developers avoid that.

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
theDBguy
post Apr 24 2019, 08:32 PM
Post#3


Access Wiki and Forums Moderator
Posts: 76,425
Joined: 19-June 07
From: SunnySandyEggo


Hi,

Welcome to UtterAccess!
welcome2UA.gif

We have a few examples of how to automate FE update deployment in our Code Archive. It should help ease the burden of copying the new FE in every user’s computer.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
AlbertKallal
post Apr 24 2019, 11:07 PM
Post#4


UtterAccess VIP
Posts: 2,852
Joined: 12-April 07
From: Edmonton, Alberta Canada


Unfortunately, that setup just causes more problems than the time you save.

And, worse, if one user has some issue, then often say a stuck filter, or something else goes wrong with a form, then now all users are effected. So one frozen workstation can make for a bad day – but a bad day for everyone!

We all install word on each computer.

We all install say Excel, or Outlook on each computer.

Now when using word, or say Excel, such users might open some documents on a shared folder, but they STILL are running a local copy of their software.

You not just trying to share a front end, but now have to put on a developers hat.

You can just like Excel, or Word, share some data from some server folder, but the code, the UI, and the “software” those users are running all runs on the local PC.

The same goes with Access. You are “creating” software that runs.

There is quite a significant difference between sharing some data file, or document as opposed to “software” with a user interface.

Your software (like most) has two parts:

The data file part – maybe shared on a folder.

The program part – that’s installed on each workstation.

Now, likely your application does not have a file->open to open the data file, but in some cases, we actually do have such a setup.

So, if word was shared, and one user had an issue, then everyone else in the building could be effected by this mess or damage to the “application” part.

Even just simple things like a user changing a default printer – do you want that to now effect everyone?

The best way to think of this?

Well you installing all other software (Outlook, Word, and Excel) on each computer. This “isolates” the software and allows it to run and do things without effecting all other users.

Since you ALWAYS installing all that other software on each PC, then why would you not do the same for your software?

Just because you purchase, or build the software is not a reason to break this long time rule.

You are installing all other software on each workstation, so you should continue that long time approach with your software.

So, if one user has a computer lockup, or some problem with an application, at least that computer is isolated, and things they do or change for their running copy of software will not affect everyone else.

So, as a developer, one wants to make a distinction between some data files on a shared folder vs that of applications and code and a user interface (UI) that you install + run on each computer.

You doing this for likely EVERY other software system you deploy, and thus now your software should not be treated any different.

And, my software often uses some temp tables in the FE for scratch work etc. – with one user I am free to do this – if I shared the FE then I can’t use those temp local tables anymore.

About the only difference here is you “can” break this rule and try doing this.

You can give it a try – but you likely find that one user’s issues and problems will now spread to every other user. And then they will not trust your software, and then they lose faith in your system, and will want to use something else.

Even if you do this 100% correct, I bet from time to time you have some issues – so might as well use a setup that reduces issues and problems – since you have enough of those anyway!

As others noted, there are quite a few approaches to rolling out your new next great version of your software. So, you better off to spend some time building some kind of automated roll out.

And if you did/do share that front end, then you have to kick everyone out of that FE to roll out a new version – that tends to be a real hassle.

If you have an automated roll out, then you release it, and maybe some users are still working on the older version until they exit + re-start, but again that is a far better approach then being locked out and prevented from rolling out a new update – since all users will have to exit that FE. This can be painful when the one computer is in some locked room you don’t have a key, and that person gone home for the day. Now you can’t even roll out the update to current users.

At the end of the day, all their software is installed + runs on local workstations – it just a plain Jane fact of our industry and how we do things.

Last but not least?

Give it a try – but don’t say we didn’t tell you this is a bad idea! Some people most certainly have gotten away with this setup, but a heck of a lot Access developers just gave up due to additional issues and problems.

This is not something you must do, or have to do. It only a good recommend.

Good luck!

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada


Go to the top of the page
 
penfold098
post Apr 25 2019, 11:48 AM
Post#5



Posts: 149
Joined: 5-March 14



I have used and had great success with this version from AncientCPU.

FE updater
Go to the top of the page
 
DanielPineault
post Apr 25 2019, 02:40 PM
Post#6


UtterAccess VIP
Posts: 6,906
Joined: 30-June 11



You are better to setup a vbscript that copies the master server file locally to the user's desktop/document/or some other location and then launches it. You never want to share a common copy of any database between users as that can lead to corruption. You may like to look over
http://www.devhut.net/2010/09/15/launch-op...bscript-part-2/
http://www.devhut.net/2015/06/30/ms-access...-to-your-users/
http://www.devhut.net/2017/04/09/setting-u...ccess-database/

--------------------
Daniel Pineault (2010-2019 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
DaveH
post Apr 30 2019, 09:19 AM
Post#7



Posts: 20
Joined: 1-May 18



As everyone else has already stated it would be madness to have an Access Database Front End hosted on a server that’s shared between workstation users via a shortcut on each workstation, just like having all your users connected via a wireless connection to the back end.

Having said that there is a strategy that I’ve used for a few years to overcome this annoyance, especially where hundreds of users (front end) are connected to the back end on a server share.

This revolves around a network strategy that is written into your front end applications to check for an update file on the server at every workstation boot. If this file is present then each workstation with the front end installed will automatically update itself from the server file so you only need to place your new front end update file on the server once, thereafter all the clients update themselves.

This also entails introducing the apps version number, more code in the front end to check the server for updates and a file naming convention (say MyAppNewUpdate_000.000.056) or similar that the workstations front ends can parse as runtime, this whilst simple in concept requires some forward planning but once implemented only requires you to copy your update to the server once and then the rest is automatic.

Go to the top of the page
 
DanielPineault
post Apr 30 2019, 09:33 AM
Post#8


UtterAccess VIP
Posts: 6,906
Joined: 30-June 11



I have such and updater, developed it in my earlier years, and abandoned it several years ago as it is much simpler and actually more effective (IMHO) to simply copy a fresh copy whenever a user launches the database using very straightforward vbscript. This guarantees that users always have the latest and greatest version of the Front-end and has the added benefit of also ensuring that the FE is optimized, not bloated ... from usage.

The other issue I faced with the updater, was users bypassing it and deciding to go create direct shortcuts to the server copy thus never receiving future updates! This is an issue with any approach though, and is remedied by folder setup and permissions.

--------------------
Daniel Pineault (2010-2019 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    23rd October 2019 - 06:11 PM