• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 848
  • Last Modified:

Access 2003: run time error 2501: The DeleteObject action was canceled. In secure/password protected mdb

Hello all,
I've been searching everywhere for the answer to this seemingly simple question, but have come up with nothing...

Basically via VBA I want to run code that deletes a form.  (ie... DoCmd.DeleteObject acForm, "FormToBeDeleted")
The problem is that I also want the code/mdb secure (aka password protected).

With the mdb secure, I get an error: run time error 2501: The DeleteObject action was canceled.
Anyone know of a way around this?

Maybe something like:
1. Pass admin password
2. DeleteObject
3. Reset admin password
0
Cristal638
Asked:
Cristal638
  • 6
  • 4
  • 2
1 Solution
 
Eric ShermanAccountant/DeveloperCommented:
Check to see if the form is open before you try to delete it.

ET
0
 
shambaladCommented:
Who will be running this code?
Do they have Admin rights?
If the form is not deleted, check its owner:
  Use menu option   Tools => Security => User & Group Permissions
                               Change the object Type to 'Forms', then click the 'Change Owner' tab.
                               What is the Owner name?
0
 
shambaladCommented:
Basically, whoever is running the code has to have 'Administer' permissions to the form. This can be done for a specific user/profile and a specific form. Or you can create a Group profile that has a set of permissions, and then add the Group profile to each of the profiles. If you are working with more than a couple users or forms, the Group profile is, by far, the more efficient approach.
Todd  
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Cristal638Author Commented:
We need to have the code locked down but want to be able to delete the form.  If I give the users admin permissions then the code won't be secure.

After much research, I'm begining to think that it can't be done.  I'm hoping that I'm wrong.
0
 
Eric ShermanAccountant/DeveloperCommented:
Why do you need to delete the form???

ET
0
 
Cristal638Author Commented:
This issue isn't just specific to the form that I'm deleting.  It's also has to do with temp table deletion, etc...  Basically anything to do with the docmd.deleteobject command in a secure database.

Everything I've seen on the subject leads to the fact that it can't be done.  So I'm going to try a different approach.  If someone can answer it correctly (that doesn't mean confirmation that it can't be done, LOL), then great...  Otherwise, I'd like to close the question and have the points refunded.
0
 
shambaladCommented:
Cristal638 -
Do you really think that there are hundreds of thousands (if not millions) of applications written in Access which can't be secured if users have to delete tables and forms?
It most certainly can be done. You should be aware, though, that really securing a database is a lot more complex than simply creating a work group file and a couple of profiles.
Probably the single, most comprehensive quide to securing your database is a book by Garry Robinson, "Real World Microsoft Access Database Protection and Security." I highly recommend getting this book. Just Google on 'Garry Robinson. The book chapter describing the Startup Options form in particular can be viewed on Microsoft's MSDN site at the following link:
http://msdn.microsoft.com/en-us/library/aa200349(office.11).aspx
You will need to disable the Shift-Bypass key. I have included some subroutines below that do that.
When one of my applications starts up, I run a subroutine that prevents anyone from trying to open the app using the 'Admin' profile.
You should consider converting the database to an MDE, which not only will remove any visibility to the app's code, it will also prevent someone from exporting unwanted code (like a different AutoExec macro) into the database.
Check out the Windows Manipulation utility from Peter's Software at:
http://www.peterssoftware.com/winmanip.htm
This software does a great job of hiding the Access window so that the only thing visible is the form itself.
There is an option to 'Hide' objects in Access options. But you can really hide the tables so that even a person with 'Admin' authority working from a database with the 'Show Hidden Objects' byte checked cannot see the tables when using the Import Objects utility. This process is described here:
http://www.utteraccess.com/forums/showflat.php?Number=1527390&fpart=all#Post1527390
The above should give you a good start along your way to really securing your database.
Once you have secured your application to the extent that any regular user can only use the forms you design, you can now circle back to managing permissions to your objects. As I wrote in a previous post, you can set up a group profile that has the permissions to delete the objects you are creating in your application You should note this does not have to mean that you give this group profile 'Admin' rights. You would then add this group profile to the individual profiles.
Private Sub DisableBypass()
   SetBypassKey (False)
End Sub
 
Private Sub EnableBypass()
   SetBypassKey (True)
End Sub
 
Private Function SetBypassKey(bState As Boolean)
    Dim db As DAO.Database
    Dim prp As DAO.Property
    Const conPropNotFound = 3270
    On Error Resume Next
    
    'Point to current db
    Set db = CurrentDb
    
    'Set the database property
    db.Properties("AllowByPassKey") = bState
    'Check for errors in setting 0=success,3270=property does not exist
    If Err.Number <> 0 Then
        If Err.Number = 3270 Then
            'Property does not exist, lets create one
            Set prp = db.CreateProperty("AllowByPassKey", dbBoolean, bState)
            'Add property to the database
            Err.Clear
            db.Properties.Append prp
        End If
        
        'Display errror if property exists but fails to set or failed to create property
        If Err.Number <> 0 Then
            MsgBox "Error setting property " & Err.Description
        End If
    End If
End Function
 
Private Sub StopAdminLogon()
   Dim strUser As String
   ' Do not allow user to sign on as 'Admin'
   strUser = CurrentUser
   Select Case strUser
      Case "Admin"
         MsgBox "Not a valid logon ID" & NL & _
               "application will now close."
         Application.Quit
   End Select
End Sub

Open in new window

0
 
shambaladCommented:
There's also a technique called vPPC (Virtual Password Protected Connection)
http://www.utteraccess.com/forums/showflat.php?Number=1243573&fpart=all#Post1243573
0
 
shambaladCommented:
BTW - I should caution you to be very careful when trying such techniques as converting an application to MDE, or using the 'Windows Manipulation' procedures to hide your Access window; you could end making the application completely inaccessible to yourself.
Always, Always test these techniques on a test copy of your application first.
Todd
0
 
Cristal638Author Commented:
Hi Todd,
I'm going to assume that you weren't intentionally being condescending with the way you started your prior reply (ID:24194565).  Of course I don't believe that a database can't be secure if the user needs to delete an object.  That's why I asked the question in the first place.  I was just presented with an obstacle that I wasn't 100% sure how to get around.  In prior releases of access, deleting an object in an MDE wasn't possible.  So I didn't even consider going down that road (my bad).  Now it look like MDE's in 2003 allow this functionality and looks like just the thing I need, but I'm a little concerned about what, if any, are the issues that could arise by using an MDE create with Access 2003 but running on a pc with only Access 2007 installed.  There's a chance that some of the users of this application will be upgrading to Access 2007 in the not so distant future.
0
 
shambaladCommented:
Cristal638 -
Sometimes, in the morning, things are not written as gracefully as they could be. I need to watch out for that.
I probably should have gotten a little clarification on what you meant by 'securing' a database. It has been my observation that, by using multiple techniques, you can make an Access database secure from all except the most determined technical expert. In the final analysis, though, the only way to arrive at a really bulletproof security solution is to have the back-end data tables secured in a server-based database like SQL Server or Oracle (although using a properly secured Access application as the front end is perfectly viable under those circumstances).
So the deletes are working for you in your current environment. That is good. That would appear to resolve your original question posted here.
Now, as to your question about running a 2003 MDE in Access 2007, now that is an entirely new topic. If youve worked with it, youve no doubt observed that Access 2007 is a radically different beast from Access 2003. Just be sure you have plenty of time to test everything out before you make the jump. Here are some links to get started with:
http://www.le.ac.uk/its/cfsxp/office2007/access2007.html
http://office.microsoft.com/en-us/access/HA101662271033.aspx
http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_23456448.html
Good Luck,
Todd
0
 
Cristal638Author Commented:
Thanks Todd and I completely understand how emails, IMs, chats, etc... especially first thing in the morning, can be misconstrued to reflect a negative overtone.  I've been called on it myself in the past, which is why I gave you the benefit of the doubt.  The way I've decided to handle the issue(s) is this:
Deploying an MDE front end keeps the prying eyes from the code while also allowing the code to run using the DeleteObject command.  As for worrying about using the 2003 MDE in a 2007 environment, Ill just convert the mdb to 2007 (testing it to death, of course) and then create a 2007 MDE.  Ill cross that bridge when I get to it.  For the record though, Im not a fan of 2007.  Im really not sure what they were thinking, but thats a story for another day.

Thanks for your help&
Dave
0

Featured Post

Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

  • 6
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now