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
> How To Handle A Dynamic Fe, Office 2010    
 
   
KRoth472
post Nov 16 2011, 03:07 PM
Post#1



Posts: 188
Joined: 12-August 10



Hello UA,
I am looking for feedback on how any UA members handle a Split DB where the FE is always changing. Basically I know when I put a database onto a existing server I am not done with it. The DB FE is constantly changing to my users needs and sugggestions. I tweak a little something on one form or fix a spelling error on another form and right now how I handle this is everyone uses a shortcut to a master FE and when I need to work on it for whatever reason I just ask everyone to stay out of it and bypass to design mode using the shift key. This works good when you are all in the same place but now the databases I am creating are much larger than before and my management team invisions them being used in different locations. My original thought is to create a table in the BE and store the current version of the FE in the table field. If someone attempts to log onto the FE (i've created a password form for credentials) through the password form it checks a logon form textbox or label against the BE database and does a Docmd.close database if the two credentials don't match. Does anyone else have any ideas or suggestions. Any help would be much appreciated.
Also another question...I am relying heavily on global variables to store information in modules for Queries. When ever the program debugs of course you lose the global variables. I am wondering how you all deal with this issue. I was told to use tables and not global variables but this was after much effort went into designing the modules. What are your thoughts?
Thanks!
KR
Go to the top of the page
 
J.D.
post Nov 16 2011, 03:34 PM
Post#2


UtterAccess VIP
Posts: 4,506
Joined: 31-January 00
From: Columbus, OH USA


Everyone using the same FE isn't a good idea as it can still cause corruption issues and as you are learning, making changes can be difficult at best. ideally, the FE should be on the user's local PC and get a fresh copy from a centralized location where the master is stored. And from a best practice standpoint, that isn't even the copy you edit. you make a copy (or keep an up to date copy) on your local PC for development and then "publish" any updates to the master (copy up the file) and then that gets distributed out to the masses and each one's local PC.
How to do that? search the UA code archive forum as there are several examples and styles for handling this. One way I used to do it is to have a table in the BE that had the FE version number (date and release number sort of thing). I then had a local table in the FE that had the version number. When I made updates, I'd increment the version number in the BE table, then in the on open event of my first form (menu or switchboard)on the front end, i would compare the two values and prompt the user to get an update (or run a bat file that did the copy command) from the server. Most of the options you will find employ this basic idea to different degress.
recently however I invested a few bucks into this auto updater http://www.autofeupdater.com/ It's slick and easy to use and it handles the whole thing for me from start to finish, there is no leg work involved for the initial set up. Just get the user to execute a link generated from the program via email and the file is copied down and ran and they get a nice desktop short cut with a custom icon and every time they run the application it checks first for a new/different version (uses file mod dates I think) and copies down as need be. no changes to your current db required, it's just a matter of learning the program. I read the directions and had it up and running in less than 30 min (all inclusive). a day or two later I experimented adding the custom icon and what not and worked through changing a few options but again flawless, just a matter of learning it, and it's a very small learning curve.
We here at UA usually promote the do it yourself free style, which I'm all for, but for the price, this is well worth it and I have nothing to gain by it (I'm not the developer). you do get a full function 30 day trial so it's costs nothing to start and play with.
Hope this helps,
Go to the top of the page
 
J.D.
post Nov 16 2011, 03:44 PM
Post#3


UtterAccess VIP
Posts: 4,506
Joined: 31-January 00
From: Columbus, OH USA


docmd.close closes the currently open form (that executed the command). You would want to use Application.Quit to quit Access as a whole. As far as you use of global variables, we'd need to see some examples of your code and use n queries to make better suggestions, but I would initially agree which the using a table advice. I often have a tblLocalVariables table where I store what may be considered global variables.
ember your global variables if they are indeed variables are unique to a session of Access. That may be desired but it may also not be desired that you want everyone to always have the same variable values and if you change them everyone should see them immediately, thus the table idea.
Go to the top of the page
 
KRoth472
post Nov 18 2011, 08:34 PM
Post#4



Posts: 188
Joined: 12-August 10



J.D.
Thanks for the info. I think I am leaning towards doing the current version in a table suggestion since it is what you suggested and it is what I was thinking about doing anyways. As for the global variables they are only meant to be used in the current session and a the way I found to deliver info from form to form or from query to query. I will take a look at the link you suggested but now I am wondering when you prompted the users to get the newest version did you just have them copy it from the server themselves or was there a dialog involved through access? Yoiu mentioned a .bat file. Is this hard to do or would I be best served using the autoupdater? Thanks agian!!!
KR
Go to the top of the page
 
tina t
post Nov 19 2011, 12:37 AM
Post#5



Posts: 6,076
Joined: 11-November 10
From: SoCal, USA


the following UA topic addresses your question about global variables in some depth. i posted a link to a particular post, but the entire thread is interesting.
persistent collection of global variables
lso, i'll second J.D.'s recommendation of Tony Toews' AutoFEUpdater. it's been around for quite some time, with periodic updates/enhancements, is widely used, and so is well field-tested. i convinced the IT manager at my job to make the very modest investment in it, and it has made my database-deployment life incredibly easier than it used to be! i have half a dozen different FE dbs running in various combinations on 60 or so PCs at work; it's absolutely wonderful to update a master FE, copy it to the server, and let the users download it to their computers themselves - without them ever even needing to know about it!
and no, i don't know Tony personally, though i have emailed questions to him about his program and he has most graciously answered. and i don't have any connection with his program at all, other than being a very satisfied customer! :)
hth
tina
Go to the top of the page
 
theDBguy
post Nov 19 2011, 12:19 PM
Post#6


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


Hi,
ardon me for jumping in...
THere are some more links to other Auto FE Updaters:
Bob Larson's Front-End Auto-Update Enabling Tool
Bill Mosca's VBScript
Stephen's Code Archive Demo
Peter Hibb's Front End Updater Utility
Jason's Code Archive Demo
Another Code Archive Demo
I'm sure that's not the entire list.
Just my 2 cents... 2cents.gif
Go to the top of the page
 
KRoth472
post Nov 21 2011, 01:57 AM
Post#7



Posts: 188
Joined: 12-August 10



Thanks guys...good info shared in this content. I really appreciate the help!!!!
R
Go to the top of the page
 
Tiesto_X
post Nov 21 2011, 04:44 AM
Post#8



Posts: 335
Joined: 27-July 10



Sorry for jumping in, but I must also say BIG thanks!
Go to the top of the page
 
Tiesto_X
post Nov 21 2011, 06:30 AM
Post#9



Posts: 335
Joined: 27-July 10



Just one question. What if users use Server Remote Desktop? Ok, they all got own Desktops (using Windows Server CAL), but folders and other things are the same. How to handle this?
Go to the top of the page
 
gemmathehusky
post Nov 21 2011, 06:57 AM
Post#10


UtterAccess VIP
Posts: 4,725
Joined: 5-June 07
From: UK


the key to all of this, is this:
On the back end, have a table/field with "required version"
in the front end, have a table/field with "this version"
The first thing the front end does when it starts up is
a) links tables, if not already linked
b) checks the version - if the version "this version" in the front end is less than "required version" in the back end then either
-1 - automatically refresh the front end with the new version, from a "master location"
-2 - give the use a message, and let him update the version manually
All the updaters will be variations on this general idea.
Go to the top of the page
 
gemmathehusky
post Nov 21 2011, 07:05 AM
Post#11


UtterAccess VIP
Posts: 4,725
Joined: 5-June 07
From: UK


I have to say I use globals extensively. The key to this is to eliminate run-time errors - so make your code robust by adding extra stuff to validate everything that can go wrong. Add error handlers to any location that still might fail. Your users should never ever see a debug/end msgbox - and then you won't have any problem about variables losing their context.
o be honest, a high proportion of code tends to be necessary to manage user interactions. You really do have to make stuff idiot proof - because if there is any way to "crash" a program, some one WILL manage to do it, somehow.
so check for sensible values of entries, check for dates not being future or advance, check for 0 in divisions.
Hard ones to anticipate with recordsets are Error 3265, item not in collections, and trying to assign a string that is too long for a field.
Any time a form or report doesn't open - either because the underlying query fails, or there is no data, and you decide to close it - you get a 2501 error. Have your code anticipate 2501 errors.
understand the intricacies of error handling. a error handler is not re-entrant. once your error-handler has tidied up, you need a resume statement to reset the error handler for next time. A common problem is an apparently non-firing error-handler, caused by this problem, when your error handler just uses goto to carry on processing, rather than resume
make sure variable arguments are set correctly, or that your code allows for nulls, as these will generate run time errors otherwise.
Go to the top of the page
 
Tiesto_X
post Nov 21 2011, 09:03 AM
Post#12



Posts: 335
Joined: 27-July 10



Thank you gemmathehusky!
It took me 4 hours but I finally find solution for my problem.
HAs I said before my users use Remote Desktop to run application which means they share same folders but different Desktops.
Odid what you said so I created:
CurrentVersion table on FE and field Version (Date)
NewVersion table on BE and field Version (Date)
I use Date as version. So, CurrentVersion holds old date in Version record and NewVersion holds today date in Version record.
Then, OnLoad event of Login form i put code:
CODE
Dim strCV As String
Dim strNV As String
strCV = DLookup("Version", "CurrentVersion")
strNV = DLookup("Version", "NewVersion")
If strCV < strNV Then
    If MsgBox("You have old version, do you want to take new one?", vbYesNo, "New version") = vbYes Then
    Call Shell(Environ$("COMSPEC") & " /c  c:\NewVersionLocation\NewVersion.bat ", vbNormalFocus)
    End If
Else
MsgBox "Version is ok"
End If

The .BAT file got this code:
CODE
COPY C:\NewVersionLocation\FE.accdb C:\Users\%username%\Desktop\FE.accdb

No matter if your old FE is loaded, it will Overwrite with new one.
After that user need to Restart FE to start new version.
HTH to someone.
Go to the top of the page
 
KRoth472
post Nov 21 2011, 04:30 PM
Post#13



Posts: 188
Joined: 12-August 10



@ - gemmathehusky,
Thank you for the info. You helped validate what I did.....
@ - Tiesto X,
I am wondering from your code in Access where does the application close? Does the .bat file overwrite without the Access app being closed? Are you still prompted to replace like you would be in a cut and paste situation?
THANKS!
KR
Go to the top of the page
 
KRoth472
post Nov 21 2011, 04:34 PM
Post#14



Posts: 188
Joined: 12-August 10



@ - Tiesto X
lso, where do you put these files? Is the .bat part of a packaged bundle you force to the users? Thanks!
KR
Go to the top of the page
 
Tiesto_X
post Nov 22 2011, 03:26 AM
Post#15



Posts: 335
Joined: 27-July 10



Hi,
There is no need to close application. .bat file overwrite opened (OLD) application without prompting any massage.
But there is need to close Current (OLD) application, and open New one.
Omade some changes to make it a bit nicer, so user no need to do it manual.
Code is checking versions, run .bat file and close Application:
CODE
Dim strCV As String
Dim strNV As String
strCV = DLookup("Version", "CurrentVersion")
strNV = DLookup("Version", "NewVersion")
If strCV < strNV Then
    If MsgBox("You have old version, do you want to take new one?", vbYesNo, "New version") = vbYes Then
    Call Shell(Environ$("COMSPEC") & " /c  C:\FolderName\TakeVersion.bat ", vbNormalFocus)
    DoCmd.Quit
    End If
End If

and .bat file Overwrite Old version and open Copied one.
(Coping from C:\FolderName\TakeVersion.bat to users desktop, then starts FE.accdb from users desktop)
CODE
@ECHO OFF
ECHO Updating...
COPY C:\FolderName\TakeVersion.bat C:\Users\%username%\Desktop\FE.accdb
START C:\Users\%username%\Desktop\FE.accdb
EXIT

My case is specific, because users run application from their own desktops from same server.
If users run FE from local desktop and BE is on server, then you put all files (BE, FE, .BAT) into server C:\FolderName
Then code is a bit different:
CODE
@Dim strCV As String
Dim strNV As String
strCV = DLookup("Version", "CurrentVersion")
strNV = DLookup("Version", "NewVersion")
If strCV < strNV Then
    If MsgBox("You have old version, do you want to take new one?", vbYesNo, "New version") = vbYes Then
    Call Shell(Environ$("COMSPEC") & " /c  \\FolderName\TakeVersion.bat ", vbNormalFocus)
    DoCmd.Quit
    End If
End If

CODE
@ECHO OFF
ECHO Updating...
COPY \\FolderName\TakeVersion.bat C:\Users\%username%\Desktop\FE.accdb
START C:\Users\%username%\Desktop\FE.accdb
EXIT

I didnt tested the second solution.
HTH.
Go to the top of the page
 
KRoth472
post Nov 22 2011, 01:52 PM
Post#16



Posts: 188
Joined: 12-August 10



Tiesto X,
Thanks for the info. I will give it a try. Looks like it should work.
KR
Go to the top of the page
 
Tiesto_X
post Nov 22 2011, 02:32 PM
Post#17



Posts: 335
Joined: 27-July 10



br />If anything, I'm here to help.
GL
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    21st September 2019 - 08:41 PM