I want to allow user to update data from form, but not from direct table. I added Before Change event on table, and raising error if the user group is 'basic'. This is working as expected if I enter data in table. But, it is also raising error even if saving data from form. Can anyone help me to resolve this issue?
Thanks in advance!
In general the way to deal with permissions in Access is to only ever show your users the forms; they should never directly interact with a table or query. So instead of adding Before Change code to your table, you instead want to hide the table.
The things you need are in the Current Database section of the Access options. For this example I'll assume you just have the one form, but the same applies if you have many forms and a "Home" form.
Use the "Display Form" dropdown to select the form you want the user to see when they open the application.
Un-check "Use Access Special Keys" to prevent keyboard shortcuts showing objects you don't want shown.
Un-check "Display Navigation Pane" to hide the object list.
Un-check "Allow Full Menus" to prevent users from creating new objects (or use other database development functions)
With this done, the user will see only the form interface you selected and the basic data entry toolbar.
Note that when you want to make changes to the file as a developer you must hold down Shift when opening the application, which will display the navigation pane etc. Of course, any user who knows about the Shift override could do the same. Which is why distributing in a compiled accde, which cannot be unlocked, is a good idea. But you need to set up the application using the above options before that matters.
Related
I am developing an MS-Access application with the data sitting in a separate backend database (Also MS-Access). The main form contains a button to open a settings dialog, an exit button (both in the form header) and a navigation control with a number of tabs showing subforms in form details. The settings dialog is a popup. In the dialog the user can change the path to the backend database and all linked tables will be relinked automatically if the user saves settings. This works all very well.
However, after closing the dialog, requerying the active subform has no effect, only if I close and reopen the form (e.g., by clicking a different tab) would it show data from the new (relinked database).
And I think this has somehow nothing to do with my relinking vba code.
I tried to open my subform directly and used the Linked Table Manager, with the same result. Hitting the refresh button on the ribbon does nothing, only when I change to design view and back to form view, the data in the form would be updated.
I also tried different combinations of repaint, refresh and requery, but to no avail.
I use requery extensively in my code and it works well, but it seems not after a simple reconnect of linked tables. The different backend databases have the exact same structure, they are just duplicates with some records removed to have test cases.
What's going on here?
Regards Oliver
Thank you Jeffrey, Your answer pointed me in the right direction. I wasn't aware of the SourceObjectproperty. This is, however, a property of the subform control that holds the actual subform. In my special case of a navigation control, it is the navigation subform control that holds the active subform which is defined on the tab as NavigationTargetName.
So my code looks as below:
' ContentContainer is the NavigationSubform control
srcObjStr = Me.ContentContainer.SourceObject
Me.ContentContainer.SourceObject = ""
UpdatePathes 'Relinking
Me.ContentContainer.SourceObject = srcObjStr
There isn't even the need to requery. Very nice.
Regards Oliver
I think if you use the SourceObject property of the subform instead of binding them you could force an update without closing your forms.
Form_myForm.mySubForm1.SourceObject = ""
Form_myForm.mySubForm2.SourceObject = ""
run your relink routines
Form_myForm.mySubForm1.SourceObject = "mySubFormQuery1"
Form_myForm.mySubForm2.SourceObject = "mySubFormQuery2"
Form_myForm.mySubForm1.requery
Form_myForm.mySubForm2.requery
This is just speculation, I've never had a situation where I needed to relink at runtime, but I think it should work.
I have a number of letter templates which I want to populate with data from my MS Access database and am unsure how to go about it.
The way I want it to work is as follows:
User is viewing a record within MS Access;
User presses "Generate Letter" button;
Choice of .doc/.docx templates (which I already have) appears;
User selects template and presses 'OK';
Letter is generated and populated with data from active record;
Once user is finished with letter, pressing 'Save' will attach it to active record;
(Ideally) any generated letters will appear within the attachments of each record (I have already created the attachments section - this is just for context)
How do I go about achieving this in MS Access 2013? I cannot seem to figure out nor find anything which deals with this specific problem.
The "Generate Letter" button should produce a pop-up form. That form will have either a combobox or listbox (depending on what you see fit) that displays the list of available templates, as well as an "OK" button.
Alternatively, you can place the combobox/listbox on the main form and the "Generate letter" button next to it, assuming your main form has a subform that's displaying the data.
You will then do a Mail Merge with only the active record. Once that's done, the most difficult part will be storing the "Save To" path in one of the fields. You could possibly use an OLE field, but saving the path to the file is my preferred method. I say it's the most difficult part because I'm not sure how you can capture that without using a standard dialog box.
For the word merge and selection of a template, try my super easy word merge example here:
The sample I have can be found here:
http://www.kallal.ca/msaccess/msaccess.html
Above sample is specially designed to enable ANY form with ONE LINE of code.
Thus, each time you build a new form, you can word merge enable it with great ease. (with one line of code).
Make sure you read the instructions from above, and you should eventually get to the following page
http://www.kallal.ca/wordmerge/page2.html
The above handles all of your issues a requests with the exception of the last step in which you save the path name to the document (and I recommend you don’t save the document in the database – but only path names to a folder). Grabbing the file name is also possible with my sample.
I've been working on a database for a little while here, and while I'm still kinda new to MS Access, I do know how to code some basic things. Nevertheless, what I'm trying to do isn't so much needed as it is something that I would like to add in just to make the database easier to use.
What I've got right now is a form that will allow a user to put in first name, last name (UserID will concatenate both last and first names, respectively) and the password, but here's the thing: If a user opts to close out of the form before saving, I've successfully implemented the On Unload event to ask the user if they'd like to save said information before closing the program. The issue is, it does that ANY TIME the form closes. Is there some way I can have the Save Record button be tracked, or be able to track any sort of updates on the form itself?
I can think of two potential solutions (not in any order of preference):
If the form is as simple as you say (just 4 or 5 controls) then when it loads save the information in some "state" in your form. Then, in the Form_Unload event, check to see if the form content is different from the one in your state. If it is, prompt the user if they want to save the data, otherwise carry on and do nothing since there have been no changes. Of course, if the user at any time presses the "Save Record" button, then you'll also need to update your state to contain the latest saved information.
Another way is to keep a clean/dirty flag for each control that you are interested in (username control, password control, etc.) and that the user can type data into. Most/All controls have an event to track if the data inside them has changed. So use that event and set the dirty flag to True if any edits happen in each control. When the user presses the "Save Record" button, then the flags should become clean, since the information has been saved and is up-to-date. Again, in the Form_Unload event, check the flags and if any are dirty then prompt the user to save, otherwise carry on and do nothing.
I am trying to update an existing Switchboard in an Access database. When I click the "Switchboard Manager" button, I get the error "Invalid Procedure Call or Argument." Any ideas what might be causing this or how to fix it?
The switchboard manager stores your settings in a table named Switchboard Items. Open that table in Datasheet View, and see whether you can spot any stored values which don't make sense. Sorry, I can't tell you specifically what doesn't make sense ... hopefully you'll know when/if you see it.
Actually that error message sounds to me more like a problem with the form itself. So rename the form and table, and create a new switchboard, which will also create a new copy of the Switchboard Items table.
If that new form/table combination works correctly, delete or rename the new copy of Switchboard Items. Then rename the old saved version of that table back to Switchboard Items again and try it with your new form. If the problem was solely due to the form, your new clean copy of the form should now work with the original version of Switchboard Items.
Note that many Access developers avoid the switchboard manager. It is limited and brittle. You can substitute custom forms which command buttons for your menu options. That may seem like more work, but it's not a huge amount of extra work, and you will be protected against switchboard manager breakage.
I was wondering if there was any way of changing the background in access. The standard grey is ok but I would like to change it to an image that shows instructions or what was updated last. Also, if I can allow a user to change the background to an image of their choice that would be cool as well.
Can this be done
To be honest, I'm not sure if this is possible or not, but if it is, I'd advise you not to do it. Why?
Users will expect instructions under a help menu or on an intro
splash form
They will expect info. like what was updated last to appear in more
conventional places like the status bar
Allowing users to personalise your application with their photos can
make your application look pretty bad and increase load times.
Only advice though - good luck with it!
I have been able to allow users to change the background of the database. It works great and it works no matter what computer they log onto the database from. I did have a problem with remote users so I added a macro that allows them to disable the functionality. It works great. It was a little complicated to se up initially. Some of the modules below may have more stuff contained in them then what is needed for the purpose of this question. But here is what I did to make it work:
Add the Following modules to your database: modChangeMDI, SetBackgroundImage, and clsCommonDialog
Link to a zip file containing the code for the above modules: http://www.filedropper.com/changebackgroundimage
You can set the default location that a users sees when the search for file dialog pops up. This is located in the ThisFileToOpen function of the SetBackgroundImage module.
clsCommonDialog <-- Used to open the find file dialog box
modChangeMDI <--Used to change the background image
Create a table called $BackgroundLocation with the following fields. On my database this is contained in the backend database.
ID (AutoNumber, Primary Key)
UserID (Text, Required, 250 in length, don't allow zero lengths)
BackgroundLocation (Text, 255 in length, not required)
DisableBackground (boolean)
Create an AutoExec macro and add an action that runs the code SetTheBackgroundPictureOnStartup (1)
Create a BackgroundDisableEnable macro and add an action that runs the code DisableEnableBackground()
Create a BackgroundSet macro and add an action that runs the code SetTheBackgroundPictureOnStartup(2)
Then assign the BackgroundDisableEnable and the BackgroundSet macro to their own menu item.
When the database opens it will run the AutoExec by default.
You can use a start-up form as I suggested above. You can even base the start-up form on a comments table that can be edited by the users and will display the most recent and / or relevant information. The form can be displayed at start-up and then referred to at any time by the users.
In the past, I have included a ? button on forms that open such a form at the relevant page.