Distributing New Access App using LAN: Is this a reasonable approach? (1 Viewer)

[mgav]

I'm a new Access user and currently figuring out how to send my split db to a small company.
I don't believe I need an Installer since all users have full versions of Access on their personal machines (am I wrong?)

Here is the process I'm considering:
1. send the split db (BE and .accde FE) and a batch file to the network admin and have them store the 3 files in a network folder that all users can access.
2. Then have each user create a shortcut to the batch file on their computer.
(having users do this might open a can of worms), is it possible to email the shortcut to each user?
3. The batch file would set the file path to the shared folder FE file. Then delete the existing FE (if they have one), copies the current FE version to their local PC and opens the app.

I believe this approach also solves the future problem of distributing updates to the FE.

Questions:
1. Is this a professional and reasonable approach?
2. Should this be a one time process where the batch file shortcut is then removed from the local PC so moving forwared, the user would open the Access app directly?
3. If yes to number 2, how do I manage udpates? Is standard practice to create a FE table that lists version numbers, and also include a module that checks the users version against the network file version, then removes the local copy and installs the new version?

Edit:
why is a batch file preffered over simply writing a module in the FE that:

• Front end tests if it can read a predetermined table in the BE
• If it can read the table, its all good and the code terminates
• if it cannot read the table it reads a configuration txt file that resides in the same folder as the FE. The configuration file stores the full path to the BE
• if it cannot locate the BE, it displays a file open dialog box asking the user to locate the back end

 

[dashiellx]

I do something very similar.

I also have the batch file check to see if there is a shortcut on the user's desktop and if not add it. This way, the user only goes to the network location one time to run the batch file. From then on, they just use the shortcut.

 

[theDBguy]

Edit:
why is a batch file preffered over simply writing a module in the FE that:

I am not sure it is the preferred approach. As you said, there are plenty of ways to distribute or auto-distribute the FE to the users. I think it's mostly a personal preference that depends on each individual situation or network environment.

 

[The_Doc_Man]

IF your local network's IT czar allows it, this is a simple way to work. However...

is it possible to email the shortcut to each user?

Not unless you know the network directory structure of the target location.

1. Is this a professional and reasonable approach?

At least reasonable and commonly used. HOWEVER, clear it with your IT czar. I worked in a U.S. Navy environment where I wasn't allowed to impose a script requirement on my users so they had to manually download. And that meant I had to have a special way of notifying all users of new versions. It's going to depend on how ugly your IT staff wants to be.

 

[mgav]

I do something very similar.

I also have the batch file check to see if there is a shortcut on the user's desktop and if not add it. This way, the user only goes to the network location one time to run the batch file. From then on, they just use the shortcut.

so you use the batch file to create a shortcut to the shared folders FE? Meaning all the users work off the same FE? Doesnt that lead to file corruption? I was thinking I need to have the batch file create a copy of the FE for each user on their own machine.

 

[mgav]

IF your local network's IT czar allows it, this is a simple way to work. However...


Not unless you know the network directory structure of the target location.



At least reasonable and commonly used. HOWEVER, clear it with your IT czar. I worked in a U.S. Navy environment where I wasn't allows to impose a script requirement on my users so they had to manually download. And that meant I had to have a special way of notifying all users of new versions. It's going to depend on how ugly your IT staff wants to be.

the IT czar is relaxed and the company is nowhere as sophisticated as the NAVY
I do need to get the file path though. I'm trying to keep the process as simple as possible for the users who are data entry admins. I think they could easily navigate to the shared location and copy the FE to their desktop or C drive but I'm not sure that they would be able to re-link to the BE.

 

[Gasman]

At least one person here advocates downloading a new copy each time the db is accessed?

 

[The_Doc_Man]

Probably several of us would advocate that, Gasman. Getting a new FE means that any FE database bloat gets replaced each time you reload. It also eliminates the need for testing whether the current FE version that you are using is the latest one. Finally, it VERY QUICKLY tests whether your link to the location of the back-end file is workable... at least if you keep the "master" FE next to the BE.

OK, FE bloat usually isn't much - but the FE is executing locally and is the place where Access keeps its temporary query analysis lists. Really, mostly small stuff - but non-zero bloat.

 

[Pat Hartman]

Questions:
1. Is this a professional and reasonable approach?
2. Should this be a one time process where the batch file shortcut is then removed from the local PC so moving forwared, the user would open the Access app directly?
3. If yes to number 2, how do I manage udpates? Is standard practice to create a FE table that lists version numbers, and also include a module that checks the users version against the network file version, then removes the local copy and installs the new version?

Edit:
why is a batch file preffered over simply writing a module in the FE that:

• Front end tests if it can read a predetermined table in the BE
• If it can read the table, its all good and the code terminates
• if it cannot read the table it reads a configuration txt file that resides in the same folder as the FE. The configuration file stores the full path to the BE
• if it cannot locate the BE, it displays a file open dialog box asking the user to locate the back end

1. I think so
2. The user NEVER, EVER opens the "master" copy of the FE which is stored on the server. The point of using the batch file to open the app is to force the new copy to always download. This solves any potential bloat problem, It solves the distribution of updates problem, and if the user managed to change something in the downloaded FE, it gets overwritten the next time he opens the app.
3. #2 takes care of new installations as well as updates. That is why the batch file I post includes a line of code to create a local folder and another to delete any existing FE. The first takes care of new installs, the second takes care of existing installs.

Batch files are not "preferred". They are one option and they are very simple. You can write your own application to handle version checking and downloading or you can copy one of the several options you will find posted here. I prefer the simplicity of the batch file but others prefer more complex solutions.

If your users are reliable and follow directions, always downloading the new copy will ensure that the users are always using the correct version of the FE. If your users are not reliable or you want an extra check, I do it in the FE. There is a local version table in the FE and a linked version table from the BE. My opening form compares the two versions and only opens if they match. You can use one combined version # or you can use BE version and FE version and compare both.

The first distribution is the difficult one. You need to know what the master folder will be so you can prepare the batch file. You also need to have someone on-site who can link the FE to the BE once it is placed in the master folder. This needs to happen every time you send them a new update unless you can recreate the folder path on your local system. Another option is to add a text file to the "master" folder that includes the path to the BE. In your opening code, you can compare the value in the text file with the value in the MSysObjects table in the Database (assuming the BE is ACE) column. If they are the same, the app opens. If they are different, then you run your internal relink code. If you don't have anyone you can rely on to do the relink before distribution, this is probably the best solution. You NEVER want your users to individually be navigating to find the BE and then manually relinking. Also, unless the master copy of the FE is properly linked, every time the user opens the app using the batch file method, he gets a fresh copy of the FE and will have to relink all over again.

 

[dashiellx]

so you use the batch file to create a shortcut to the shared folders FE? Meaning all the users work off the same FE? Doesnt that lead to file corruption? I was thinking I need to have the batch file create a copy of the FE for each user on their own machine.

Sorry, I wasn't fully clear. No. They download a fresh FE every time. The batch file checks for a shortcut to itself, creates it if needed, and then downloads and opens the front end.

 

[mdlueck]

Here is how I successfully do Software Distribution to maintain consistent versions of FE Databases:

FE AutoUpdate with RoboCopy / XCopy

FE on Local or Network drive???

Hallo, Eveywhere on the Net I read that the bast way to run a MS Access application is to split it and to save the BE on a network and the FE on a local PC. OK. I have a application that is splitet from the begining but at the first months it was runing FE and BE from a network and i had no...

www.access-programmers.co.uk

 

[theDBguy]

Here is how I successfully do Software Distribution to maintain consistent versions of FE Databases:

FE AutoUpdate with RoboCopy / XCopy

FE on Local or Network drive???

Hallo, Eveywhere on the Net I read that the bast way to run a MS Access application is to split it and to save the BE on a network and the FE on a local PC. OK. I have a application that is splitet from the begining but at the first months it was runing FE and BE from a network and i had no...

www.access-programmers.co.uk

Hello to all. I'm just replying to this post in order to keep an eye on it. I hope this account wasn't hacked. They posted a link to a ten-year old thread, and the poster hasn't made a post in four years before today.

 

[mdlueck]

Hello to all. I'm just replying to this post in order to keep an eye on it. I hope this account wasn't hacked. They posted a link to a ten-year old thread, and the poster hasn't made a post in four years before today.

.... but I continue to get the Access World forum post recent activities, glance through them, this thread topic of distributing FE's seemed to correlate with an old post I keep in my post collection, so thought to share it. You fault me for that?!

 

[theDBguy]

You fault me for that?!

Hello friend, you misunderstood my intent. I was trying to protect you. Since you haven't posted for four years, I just thought it was possible someone else is using your account now. My post was an attempt to illicit a response, so I can decide what's the appropriate action to take, if any.

 

[mdlueck]

My post was an attempt to illicit a response

haha.... You have your response.

 

[theDBguy]

haha.... You have your response.

And that's all I was after to try and keep everybody safe. Thank you.

 

[tmaccabe]

One approach to ensure that a FE isn't inappropriately opened/replaced/deleted on a network share is to ensure that no one but admin has modify permissions to its folder. Permissions for the BE location must include modify, so hide this LAN/WAN location as best you can. I popup a message (and shutdown) on start if the FE needs replacing (the users can keep a shortcut to the FE share on their desktop and download it themselves). This approach works in an environment where batch files and such are forbidden. I've even forced FE shutdowns using a timer that checks a table periodically. If ever you replace your BE with a cached solution (SharePoint Lists for instance) beware that forcing a FE download with every new session means users lose their cache. No need to force a new FE unless there's a critical design change. Opening a split solution is slow enough already.