application

[scratch]

When putting together the final application, you don't want the user to see all the usual default menu options.

1) Which access items should I hide?

2)Let's say I make some modifications after we go live. How can I get the new forms, modules or whatever to the .mdb in use? Would I just delete the tables in the modified .mdb and then import (File/Get External Date/import) the tables with the live data?. It's not a split db, btw.

3) Are there any other options or procedures I should think about for maintainence? For instance, right now I use the compact on close option which has proved to be very useful.

Thanks,

scratch

 

[Debased]

I would strongly suggest that you split the database. Not only does it "hide" things you don't want the user messing with, it makes modifications/revisions in the future much easier. Pat Hartman has written loads about this subject and if you have time search for that because I believe it is really worth it. She has saved me a heck of a lot heartaches!!

As far as menu's go, you can create a custom menu and have as much or as little of the default menu items as you wish. What you omit or leave depends on what the user needs are. MS Access help does give some stuff on customizing menus...

I am not nearly as experienced as many others here but I hope what little I offer is of some help. Try doing a search on this site on some of your questions. Good luck!

 

[Pat Hartman]

When you create your own custom menus, create a macro or a button accessable only to you (password protect it if necessary) that restores the standard menus. If you don't do this, you will find debugging and maintenance a real problem because YOU won't have access to the menus either.

When you split the database, it is customary to distribute copies of the fe to each workstation and leave only the be on the server. There are lots of posts here with suggestions regarding how to manage this. It is possible to have both the fe and be on a shared network folder but you won't get one of the benefits of the split if you do that.

 

[ghudson]

Check this out for a few tricks... hide all Access tool bars and menu bars

 

[scratch]

Let's say I make some modifications after we go live. How can I get the new forms, modules or whatever to the .mdb in use? Would I just delete the tables in the modified .mdb and then import (File/Get External Date/import) the tables with the live data?.

Would this work though? On paper it sounds ok and it doesn't take that long.

scratch

 

[mtairhead]

How long is too long? I've designed what I would call "shape-shifting" databases, designed for the purpose of being front-ends to as many differernt back ends as needed at a time. Speed was never an issue as long as I did not have a needless number of objects...

If you're worried about the time and speed of a split database, though, you might consider looking on these forums for some code to limit control users have over the databse. You can shut off Access's menus and even disable the splash screen... Any other control the user has can be rested from him/her via the property boxes of dbase's forms.

 

[scratch]

As long as it takes only a few minutes.

Let's say I make some modifications after we go live. How can I get the new forms, modules or whatever to the .mdb in use? Would I just delete the tables in the modified .mdb and then import (File/Get External Date/import) the tables with the live data?.

Does this work though?

scratch

 

[Pat Hartman]

I wouldn't use that technique (it does work, but you must be extremely careful since you're playing with production data). I would suggest splitting the database. That way you can just replace the front end entirely. You would only have to worry about the back end if you actually changed some table structure or added new tables.

 

[mtairhead]

Pat,

So I'm clear, are you suggesting giving a front end database, which will have the necessary forms/queries, to each user? The tables will be held in the backend, and will be accessed from the front end via linked tables.

Am I correct?

Andrew

 

[ghudson]

Pat,

So I'm clear, are you suggesting giving a front end database, which will have the necessary forms/queries, to each user? The tables will be held in the backend, and will be accessed from the front end via linked tables.

Am I correct?

Andrew

Yes that is what you do

 

[scratch]

I've long since hide the menus but a new problem showed up: it hides the menus for all access applications on the users machine. This hides for all:

Dim i As Integer
For i = 1 To CommandBars.Count
     CommandBars(i).Enabled = True
Next i

and so does this:

 Application.CommandBars("Menu Bar").Controls("Format").Visible = False

While I call the function to restore if the exit the app properly but a)they dont always do that b)sometimes they have a few instances of access open at the same time. Is there any way just hide the menus for the current app?

scratch