I have an access database that is saved in a network location so that any of the 600 employees who work at the company can access the database. When they open the main form it runs a make-table query. However there is a popup from MS Access stating "You are about to run a make-table query that will modify data in your table. Do you want to continue?"
The form will not run correctly if they do not press yes so I want to suppress this prompt so that it does not ask them. I changed the settings from the Options>Edit/Find>Confirm menu so that it doesn't show this confirmation. However, this is apparently a local setting so to enforce this every user would have to change those settings.
Is there any other possible solution to suppress the confirmation message?
There is so much wrong here, I hardly know where to start:
you can't possible have an Access database used by 600 people.
if more than one person opens it and runs the MakeTable, it will break, because you'd be making a structural change that collides between the two users.
turning off error notification is a HUGE MISTAKE. You don't know exactly which errors you might end up ignoring.
turning off SetWarnings means that you can get inconsistent updates from a SQL DML statement, and then you have no way to know which data was updated or not.
MakeTable queries do not belong in any production application. Instead, create a persistent table, and clean it out and append new records to it. But it doesn't belong in your main application -- this is the very definition of temporary data, since it's constantly being replaced, so it needs to be in a separate temp database.
you'd likely want all users to have their own temp databases so there are no collisions if more than one opens the app at a time.
Yes, from VBA:
DoCmd.ShowWarnings False ' Don't show warning popup
DoCmd.RunQuery "MyMakeTableQuery" ' Run the make table query silently
DoCmd.ShowWarnings True ' Turn warnings back on
Use DoCmd.SetWarnings False to stop the message box from popping up. Be warned, however, that this action is global to the Access application. You have to re-enable warnings with DoCmd.SetWarnings True as needed.
You can also try:
Application.SetOption "Confirm Action Queries", False
If you don't already, you may want to have a hidden form open every time the database is opened. You can use the OnOpen event of that form to run startup code like the above.
Related
So after some digging I realize that there is no built in user level security option for Access 2007. What I need to do is restrict records that users can edit based on who is logged in (they can see all the data but only edit their own). I was thinking that I could make a log in form and assign passwords and go from there, but I was wondering if there was a better method to do this.
For user privileges for read-only, read-write on forms in the database, we implemented following tables, logic.
I created a privilege table along with log-in table. Each screen in the database will have Read-only or Read-write privilege to each user. I inserted all the screen names into privilege table. Another table UserPrivilege will have users and their privileges. Assigning privilege to an user will be done only by Admin user.
A function at start of each form check swhether a specified user is allowed to view or edit form. If he/she is given read-only, we will lock all controls looping thr' controls on the form. Else, nothing to do. OR keep all the controls read-only at design them and unlock them thr' code for write privilege.
The database window is kept hidden when a version to end user is delivered. This prevents usual , simple view to tables in the database, opening forms , reports object in database window. After making mde/accde few more tweaks can be done so that user is not easily able to view tables directly. by-passing startup, special keys etc.
I have been facing this problem too. My solution (which hasn't been broken yet) is to do exactly that. Make a user's table with passwords and a log in form which reads the table for User name, password and user type. I have used two ways to proceed from there: Case statement to open specific navigation forms for that user's functions or a global variable (in a module (enumeration helps)) and an getter function that is checked within each form's open events and changes properties like AllowEdits, and AllowAdditions and even cancel the form opening if it's administrative stuff.
The most important part of this set up is making sure the users are using Access Runtime. If they use the Access version you are developing in they can snoop a little bit and get around this.
Make sure you hide the user's table.
Access runtime can be forced by making a shortcut to the DB and adding /runtime to the end of the shortcut path (with a space).
It's not perfect, but it works for my purposes and It might work for your's.
I did dot this in 2010, but 2007 should be pretty much the same.
Assigning username/passwords in Access (especially with an access back end) has a number of critical issues that are worth pointing out. Firstly, if you don't encrypt your DB, then any of your users who are savvy enough to go looking for it will be able to find it, and therefore get full access to it. If you encrypt the DB, if anyone can get access to your source code you're toast, since they will be able to see the DB user/passwords stored in the code. This issue persists if you use other SQL db's, but at least in those cases you can restrict the user supplied to the Access .accdb file to have certain permissions.
For my case, I have 3 levels of security. Firstly, I heavily restrict what I send out to make it very difficult to access the source code, which you kind of have to do no matter what. Secondly, I distribute different levels of access with different DB passwords (I'm using a MySQL back-end, you could do the same with a SQLServer back-end, but with Jet you're out of luck), so even if users could see the DB user and password, they are limited in what they can do. Thirdly, since I deploy on a corporate network, I take advantage of windows groups, and use those to filter out what is visible to different users. That way, users can only use the forms if they are authenticated onto our network. If the file discovers it's not on the network, it deletes itself and terminates.
Function IsMember(strDomain As String, strGroup _
As String, strMember As String) As Boolean
Dim grp As Object
Dim strpath As String
strpath = "WinNT://" & strDomain & "/"
Set grp = GetObject(strpath & strGroup & ",group")
IsMember = grp.IsMember(strpath & strMember)
End Function
Function GetCurrentUser() As String
GetCurrentUser = VBA.Environ$("USERNAME")
End Function
Function GetCurrentDomain() As String
GetCurrentDomain = VBA.Environ$("USERDOMAIN")
End Function
To preface this, I messed up.
I have a function that runs for each item in the database, to compare against a given value. I added a MsgBox to the code in order to check values for debugging. This function runs when the default form for the project (the one that loads when I launch Access) loads-- on every record in the database. Currently, that's slightly over 13000 items.
Is there any way to suppress the messages, launch the project without loading that form, or edit VBA from the project without launching the project?
EDIT: I've just realized that I can press ESCAPE during a MsgBox display to abort the query. Problem solved.
MS Access 2010, Win 7 on a regular formI didn't intentionally place any ActiveX or OLE things.. not even sure what they are. But anyways, whenever I put something in the code of a particular form, it says "The Expression XXXXX you entered as the event property setting produced the following error: A problem occured while MyDB was communicating with the OLE server or Active X Control
Huh? No matter what I put in the form's code, this happens. I had an empty Form_Current() ONLY which still tripped this. There's a lot of formatting and work into the form, I'd rather not scrap it.. If I leave the code window completely empty (only Option Compare Database), it does not trip the error; however then my form is useless.
I've seen things about this being a language issue, but my other forms (running the same code techniques and most of the same code) are fine and it's an english Access with an english language PC. Ideas?
Code setting off the error:
Private Sub Form_Current()
End Sub
Seriously.
I faced the same problem and I tried many things, the only (and fastest) solution that worked is to do the following:
1) Close the form that is causing the error.
2) Rename this form.
3) Duplicate it: Copy, then Paste, you will be prompted to set a name for the new form. Give it the original name.
4) Delete the original form that was causing the error.
5) Open the pasted form and it will work OK.
This solution worked fine with my database...
Regards...
Check for missing references. Make a back-up, decompile, compact & repair and if that does not work, copy everything to a new db ( http://www.granite.ab.ca/access/corruptmdbs.htm ) You may have to skip copying the problem form. Sometimes it is worth creating a new form, selecting all the controls from the old form and pasting into the new form.
you can change the language setting to have a try, the steps are as follow:
1、Open window command ,run "intl.cpl"
2、choose the Administrative item ,change the system locale settings.
Hope that can help you.
I have run into this problem many times. The error statement is horrible as it provides basically no useful information. I have found that Abu Hassan's solution typically works best (duplicate the form and delete the original) but that did not work for me on one occasion, where I had to delete an import statement that I had recently added:
imports system.collections
Once I deleted that import statement everything worked again. So if duplicating the form doesn't work then try undoing something you recently did. It could be this import statement or one similar to it.
Very strange error, that sometimes occurs in my databases too.
It seems to go wrong mostly on UNBOUND FORMS (unbound forms have no RECORDSOURCE).
What I have done recently is :
temporarily define "some" table (e.g. a config table with just one record) as the RecordSource,
compile the program (Note that this usually goes OK, even before the fix!)
Save the form.
Open the form. This should work fine now!
Delete the RecordSource, recompile and save again.
Most of the time, my forms work fine again after that.
as my experience some of errors because you use your local language in VBA statement
so you must adjust your local language as language of system from control banal >> language or region>>administrative>>change system local then select your local languages
or find the word was not English in vba and retype it by English
We have an MS Access 2007 database with a simple form displaying table data. We use the Find dialog (click the binoculars on the Home ribbon) to locate records we want. This can cause an error under specific circumstances.
Steps to reproduce the problem:
Open the form.
Open the find dialog.
Edit some field within the record.
The record is now in update mode
(you'll see the pencil in row's
"gutter" area).
Without saving the record, click on
the ALREADY open Find dialog.
Search for a record that can't be
found.
Click on the form again. The record
is still in edit mode (i.e. the
pencil still shows). Attempt a save
or edit some other field.
This message box will display
"Update or CancelUpdate without
AddNew or Edit." You can click OK or
Help buttons.
Clicking the Help button shows:
You tried to call Update or CancelUpdate or attempted to update a Field
in a recordset without first calling AddNew or Edit. (Error 3020)
On a Microsoft Access database engine database, you called the Update or
CancelUpdate method but did not use the AddNew or Edit method before writing
data to a record.
On an ODBCDirect database, this error occurs when you attempt to write data
to a record without first calling AddNew or Edit.
We’ve reproduced this in a new database where there is no VBA code. So the problem is solely within MS Access, and you should be able to reproduce it easily.
If you save the record before doing the find, the problem doesn’t happen. Unfortunately, we have users doing a find while the record is still in edit mode.
We’ve tried setting up form-level, data-field-level, and Access application level events and error handling. Nothing can detect or catch this situation. There is no way within VBA to detect if the Find dialog is active.
Does anyone have any ideas for preventing the error or a way to save the record before the find occurs? Our best thought right now is to create an AutoHotkey or AutoIt script that waits for the Find dialog to have focus. We’ll then send a Ctrl+S to save the current record to force a save.
#CodeSlave's answer suggests a possibility to me:
Instead of simply removing the binoculars from the toolbar/ribbon, instead change what the binoculars do. That is, have it call code that saves the current record if it's dirty and then launches the FIND dialog.
Now, there'd need to be some code to check that a form was open, and that it had a recordsource (testing the .Dirty property errors if there's no recordsource), and that a field has the focus, but all of those things are doable. Likely many of them (except the last) would be taken care of by showing the toolbar/ribbon only when the form is loaded, or by editing the default toolbar/ribbon when the form opens.
But this would be much less crazy than using an out-of-process solution, and your users wouldn't know any difference.
I'd suggest that you've found a bug that was introduced in MS-Access 2007. However, I have not been able to duplicate it on my copy. I presume we're both up to date on our patches, so perhaps there is something more subtle happening.
If you're wanting to force the record to be saved, use one of the the following - not a CTRL-S
if me.dirty then Me.Dirty = false ''(n.b. often the preferred method)
Docmd.RunCommand acCmdSaveRecord
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70 ''(n.b. deprecated)
The problem as I understand it, is that if they edit the form after the "find" is already open and then do the "find" the get the error.
I'd try one of two things:
Find a way to close the built in find form, and do so whenever you make the current record dirty (On Dirty)
Add your own "find" button to the form (not opening the built in find form), and hide the one on the ribbon.
The hack, work-around we came up with was to write an AutoIt script which can watch for when the Find dialog gains focus and save the record if it has changed.
We didn't want to distribute the script separately from the database, so the the script was added to a database table as a Blob. The database's AutoExec macro runs some VBA code that pulls the script out of the Blob table and starts the script.
When the script detects that the Find dialog has focus, the script runs a VBA macro in the database. The macro checks to see if the current record is dirty. If dirty, the macro forces a save. Also, the AutoIt script is stopped when the database is closed.
This is all pretty awkward, but it works.
Is there a known way, direct or workaround, by which I can disable ms access 2003 asking for user input. I have a method in which I can call a VBA procedure and I run this with a scheduled task when everyone is out of the database at around 6:30 AM. Yet I found an error in one of my queries where a space wasn't present and access was asking for that value of that column. I also found an error in some code where it results in launching the debugger and never continues (resulting in a time-out).
These are not classified as errors because I have a method in which the program sends an email on error. I need a way to disable events in which the application waits for user input, like a erroneous query or the activation of the debugger etc...
Thanks,
Matt
Sounds like you want to run with scissors. It would be better to test your changes rather than deploying them blind upon your users. However, that said...
You can disable activation of break points by un-checking "Use Access Special Keys" in the Tools->Startup options.
You can disable error checking in the Tools->Options form (Error Checking tab).
And of course you can pass parameters to MS-Access queries (rather than require user input) - see this question.
try the "on error resume next" ...