Jim Dettman
jimdettman at verizon.net
Tue May 20 13:33:43 CDT 2008
Andy, Yes, many do that. I always went for the simple approach, but just recently was considering automating the launch of the batch file. I have also seen more sophisticated setups where some type of a launcher app was used (typically written in VB so it could be a .exe), which does the version check at app startup, copies down a new FE if needed, then starts the app. And since the latter is controlled by the launcher, command line switches can be used to make sure the app is not started in any other way. It also moves all the check/update logic out of each individual DB and puts it in one place. So I have been seriously considering this approach. I already have part of my update process residing in VB (testing for proper Access version being installed, creation of shortcuts, and creating required DSN's) anyway. I'm also sensitive to the fact that my current setup does require an extra step from the user, which has been commented on in the past. But the batch concept is simple and has held up well over the years, so I'm a bit hesitant to move away from it. Moving everything into VB gains some things, but it also means I just can't sit at a clients and use notepad to fix or change something. One drawback I do have with it now is when a user has a lot of apps installed. They end up with a ton of "Update .... Application" shortcuts on the menu. I typically build all my stuff into a single app believing integration is a key factor in good software development, so this has not been a real issue for me in the past. But with one client, which I inherited, they have got a ton of little one task DB's all over the place. So a typical user ends up with a dozen or so apps installed. There are lots of ways to approach this and several free implementations out there on the net. Within the next couple of months I plan to clean up my present process one way or another. At that time, if anyone is interested, I'd be willing to share. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Andy Lacey Sent: Tuesday, May 20, 2008 2:02 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Multiple Frontend Users Saw a different take on this recently Jim. Wasn't mine so I claim no credit. It checks a version like yours does but if an update's needed it actually sets the batch file running and exits the app. The trick is in the batch file which checks for the existence of the LDB and keeps looping until it doesn't exist, then copies the MDB. In that way it is waiting for the app to quit. Takes one thing away from the user. -- Andy Lacey http://www.minstersystems.co.uk >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman >Sent: 20 May 2008 13:33 >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Multiple Frontend Users > > >Chris, > > I do that the same, but twist it around a bit; the FE has a >version table and at startup, checks the local table vs a >network "master" copy. If the rev's don't match, the user is >told to "update" (run the batch file) and the app quits. > > The batch file also serves as the install as all one needs >to do is call it from the run line or click on a link in an e-mail. > >Jim. >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Foote, Chris >Sent: Tuesday, May 20, 2008 8:22 AM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] Multiple Frontend Users > >Arthur! > >I've had similar arguments with our IT "professionals"! > >My multi-user split FE/BE database worked as follows: > >BE and copy of FE stored on network "share" along with bat >file. User has shortcut to bat file on desktop When user needs >to use database they double-click on shortcut to bat file. Bat >file looks to see if user has latest version of FE on their C: >drive, if not, it copies file for network share and runs it, >if it is latest it runs it. > >Simple! > >The only this you need to do if user gets a new machine is to >create the shortcut to the bat file. I would have automated >that if I could have been bothered ;-) > >If you need any more info of a copy to my super-duper bat file >please let me know. > >Regards >Chris Foote > > >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com >> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of >> Arthur Fuller >> Sent: Tuesday, May 20, 2008 12:53 PM >> To: Access Developers discussion and problem solving >> Subject: Re: [AccessD] Multiple Frontend Users >> >> >> I was presented with this problem recently and recommended >> this solution. >> The network support people flatly refused it. They argued >> that in their >> setup (with hundreds of users) virtually nothing on the local >> PCs was backed >> up. The local PCs can be replaced and/re-imaged anytime, and >users are >> warned not to store anything locally, otherwise it won't be >> backed up. So I >> had no choice but to put both the FE and the BE on a network >> share. The >> argument makes perfect sense to me, but I've never done it >> that way before. >> What will happen when a hundred users open a single FE? >> Should I replace the >> FE MDB with an MDE? >> >> Thanks, >> Arthur >> >> On Mon, May 19, 2008 at 10:42 AM, Dan Waters >> <dwaters at usinternet.com> wrote: >> >> > Ed, >> > >> > Even with 3 users, splitting is a good preventive measure >> to avoid data >> > corruption. You can put the Access Back End .mdb file on >> the server, and >> > put the Front end .mdb files on each user's PC. Managing 3 >> users shouldn't >> > be difficult. >> > >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >> >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com