Actually, if you want to look into it more deeply, there's an article (How To Create User Permissions and Customized Menus in MS Access) by someone you have already come across that goes into it in great depth. It even explores ways of using it more fully. I think you may like it.
Blank screen when opening a database
Collapse
X
-
Thanks for the Props, NeoPa! I was also going to suggest that article.
However, this article on Working with Front Ends and Back Ends is what I was thinking for the original issue. Please also direct yourself to the additional thread links in Post #2 of that Article.
I am not sure of your level of expertise with Access/VBA, and these articles we've directed you to are a lot to digest, but I have been using these three tricks for a handful of years and the reduction in headaches is noticeable. Now I can focus on glitches, rather than trying to properly set up my DB and publish it.
Hope this (these) hepps!Comment
-
Thank you both.
Twinnyfo... Unless I am reading incorrectly, it appears that the code that you sent (Working with Front Ends and Back Ends) is doing what I was doing (although in a much snazzier way). It appears to be relinking tables as opposed to linking tables for the first time. Am I misreading it? I'm getting that from this section...
Code:If Not ((Left(tdf.Name, 1) = "~") Or _ (Right(tdf.SourceTableName, 1) = "$") Or _ tdf.Connect = "") Then strDBName = GetDBName(tdf.Connect) RelinkTable dbACC, tdf.Name, strLink & strDBName End If
Thoughts?Comment
-
BHo15,
Yes, you are correct. That is exactly what it is doing. From my perspective, you would want to compile the DB, relink the FE tables to the network location, then deploy the FE. Then, when a user click to link to the command script, it download the most recent version of the FE and executes the FE from the local machine. But, because the links have already been established, there is no need for the user to re-link them.
An important principle here is that you should have ONE BE in ONE, shared, network location and you can have many locally-executed FEs that are all linked to that same BE. Make sense?
Hope this hepps!Comment
-
Yes, it does make sense. Unfortunately, my fellow IT Security folks at the hospital that I am writing this database for, do not want to let me have the network path that the database will live on. Therefore, I cannot set a link to the backend. I am wanting the user to be able to do this once she receives the database.
Make sense?Comment
-
Originally posted by BHo15BHo15:
My need is to write code that would allow the user to click a button and create a brand new backend database.
If, as I suspect, the latest statement is a better reflection of your needs, then you could store the path to the required BE in your [tblUser] table, along with each [UserID], and thereby have a test version for yourself along with a live version for your user. As soon as the FE starts up it authenticates the user and, using that ID, relinks the BE tables depending on which BE is assigned.
Does that all make sense?Comment
-
my fellow IT Security folks at the hospital that I am writing this database for, do not want to let me have the network path that the database will live on
It's like asking someone to clean all the objects in a museum, but not allowing them access because you think they will steal everything.Comment
-
I don't WHY I didn't find this in the first go-round, but I just found something that will work.
DoCmd.RunComman d (acCmdDatabaseS plitter)
I can add this to a button on the switchboard, and then she can create a backend database on her network.
Sigh...
Anyway fellas... Thanks for the help.Comment
Comment