FE/BE question

jonathanchye

Registered User.
Local time
Today, 21:11
Joined
Mar 8, 2011
Messages
448
Hi all,

I have an AC2010 DB ready for testing. End users want to enter data and while they are doing that I might be updating/bug fixing the FEs.

I have a few questions regarding this :

1) Should I convert the DB to ACCDE before splitting the DB?

2) If I split the DB, how can I update the FE by forms only? Can I open the FE DB file and edit individual forms while users are still free to use the forms I am not updating?
 
Everybody gets their own FE, so there is one authoritative BE on a server somewhere, and each user has his own copy of the FE on his machine. You do development in your own instance of the FE, create an accde when you are happy and distribute that file as the latest version of the FE. Different users can operate different versions of the FE since everyone has his/her own copy of the file.
This is the beauty of the split system, that data and programming are completely decoupled.
Hope this helps,
Mark
 
And you would split the database BEFORE creating the ACCDE file (and I would suggest that in the future you just develop with a split database so that you don't run into surprises when you split after getting everything done and then go OOPS! I didn't think of that. So working in the way in which the final product will be can be good.

Also, for updating the frontends, Mark already told you that each person needs a frontend copy on their machine. You work on a master copy which you can then decide on how you want to distribute new versions. There are many different ways you can do it. One way is to use an auto updater/auto updating code like the one I have created that is on my website for free (under Access Tools). Or Tony Toews (pronounced TAYVZ) has one at autofeupdater.com.

Or you can give your users a batch file as a shortcut to download the latest version each time they open it and have it open the file too. That's what we do for our Citrix users.
 
What I do is this: I have a FE/BE split. I put code in the FE so that everyone must run it from other than the file server. Then I have a test in the FE and a versioning table in the BE so that people can tell that it is time to download a new copy. (I'll get around to the auto-fe-loader when I get to a point where it is a bit more stable.)

I have my own copy of the FE in my developer directory. It is linked to a copy of the BE file in a subdirectory of my developer directory. I do my testing in that separate environment so that nobody is disrupted when I make a whoops.

When I have a clean version that is good to be updated, I copy it to a staging area. I use link manager to relink all the tables in this update copy to the real BE file. I also do compact and repair, set the database properties such as disallowing the object bar, ribbons, and certain other features. I update the FE so that it knows to what version it belongs. I run the old copy of the "real" FE on the shared BE so that I can update the version table. Then I immediately copy the compacted, digitally signed, compiled, and tailored FE to the shared FE area.

If you think about it, this way the worst that happens is that I trash my developer version and have to step back to the shared copy. My role in the database (managed by VBA, not by workgroup security) allows me to get to the Access window and call back the object bars. I also make backups of the FE before locking it down. That way, I am protected from my worst enemy - myself on a bad day.
 
What I do is this: I have a FE/BE split. I put code in the FE so that everyone must run it from other than the file server.

I get around the worry of someone running the master FE from the server or getting directly into the BE by making these folders more or less invisible to Average Joanna.

We have a group policy to disable file browsing of UNC paths and map shared folders for the legitimate users. We also append the $ to the sharenames so they are never displayed when browsing the network.

Unless they are aware of the path to the files they won't even know they are there Most of our users wouldn't know what a UNC path was anyway as they are never exposed to them.

However this does not actually lock out their access to the database folders on the server so the backend can be linked by the \\server\share path.

Sure it would not keep out someone who really wanted to get in but it keeps the stuff our of harm's way for the casually curious.
 
Thanks for all the replies! Really helped. I am happy you mentioned "server". Well I am in a tricky situation here. Most (please note the "most here :P) of my end users are using published Citrix desktops.

What is happening now is all Citrix users access a shared drive to open the DB. This shared drive is hosted physically next to the Citrix servers. So if someone not on Citrix tries to access the DB on the shared drive and he is located far from the server (our company has a few sites) he will lag. This means he will experience long loading times or even corrupt the DB!

So what I do now is force all users to use Citrix and host the BE on the shared drive. The FE is also hosted on the shared drive (just next to the BE folder).

I am wondering if it will speed things up if I setup a FE distribution folder and then ask the Citrix users copy latest version from there to their desktop.

So basically my question is : Once I have split the DB, can I move the FE anywhere I want? Can I make design changes to the FE, save the changes and move the FE around safely with the knowledge the FE will still link correctly to the BE? This is of course considering I don't add extra tables and change relationships? Will all the processing be done by the FE?

2nd question : What happens if I want to change/add tables after splitting?

Thank you.
 
Last edited:
There is not just one FE! Everybody has one running exclusively on his local machine.
 
For citrix, have the Citrix admin set up a temp folder for each user on a drive (I assume that they have it set up with Windows and Citrix installed on the C drive and then the programs installed on E or something like that) which is available to it. And then have the Citrix Admin publish a shortcut to a BATCH FILE which copies the database frontend into THEIR temp folder and opens it. In fact, that's how we do it where I work. So, here's the contents of one of our batch files which works great:

Code:
@echo Please wait while the version of the database you requested is updated.
 
@echo off
 
MD E:\BKY_temp\%username%
 
copy  R:\FE\Current\Construction.mdb E:\BKY_temp\%username% /y
 
Start /max "E:\Microsoft Office\OFFICE11\MSACCESS.EXE" "E:\BKY_temp\%username%\Construction.mdb" 
 
exit

And then we use a cleanup batch file to delete when the user is done
Code:
if exist E:\BKY_temp\%username%\*.mdb goto mde_found

goto end
 
:mde_found

del E:\BKY_temp\%username%\*.* /Q

rmdir E:\BKY_temp\%username%

goto end
 
end

(it says mdb and mde here but this is from our test server which uses mdb's but it is just a copy of the file that is on production but with the extension changed from mde to mdb - just thought I'd point that out so there was no confusion)
 

Users who are viewing this thread

Back
Top Bottom