I made a database with access, and I created dataentryform and inside it there are some subforms (I have related tables), I used query to provive these subform and without these qaueries I cannot enter data into subforms (if I delete these queries then when I open main form I see blank rectangular inside myform instead of them.
enter image description hereIs there any possible way to lock query and also subform in navigation pane?
In general, as long as the user is running an application on his own PC, you cannot prevent him from deliberately modifying/breaking it. This is true for all applications, not only MS-Access-based ones.
That said, there are some ways to make it harder to accidentally modify it:
The recommended way is to start Access in "runtime mode", either by specifying the /runtime flag on the command line or by renaming your accdb/accde to accdr. That way, the user won't have a navigation pane and can only interact with the application through the ways that you, as the developer, explicitly provide.
You can use user-level security to "lock" your queries. However, user-level security was deprecated with Access 2007. It can only be used with the old, legacy mdb format (rather than the new accdb format) and should not be used for new projects.
Related
I inherited an Access database where the (local) tables seem to be all grayed out, at least the existing ones. They only show up when I check "Show system objects" but many of these are not system tables. How can I "un-system" them? When right-clicking and going to Properties, it shows as hidden with the check box disabled. And yet if I turn off "show hidden objects" they're still there.
EDIT: Just to clarify, user defined tables are showing up as system tables and are "hidden" and I'm unable to uncheck the hidden box. This is a COPY of the backend of a split database, on my local hard drive and no one else has it open.
This would suggest that the database is being opened as read only.
It is also possible that you are using a older version of Access, and the database and tables in question have used "newer" features. In Access 2010, they introduced table macros. This feature allows you to attach triggers and stored procedure code to tables. However, if you open a 2010 database that used these features with say 2007, then everything will be set as read only. So, this is either some file permissions are attached to this file, or you are opening the accDB file with a "older" or "previous" version of access that does not support the features used in those table(s).
I would create a new blank database, and then import all of the tables etc. into that newer database. That should give you update rights.
I am building an Access Database application in MS Access 2007 which is essentially a tool for data collection which I will need to distribute to various sites to be filled out. After the sites fill out all the necessary records, they will return the tool and I will need to merge all the data from the various sites into a single database for analysis. I have 2 tables and 3 forms with a bunch of custom VBA code behind for data validation, cleaning and flow.
I have a Summary form that shows all the records currently entered. Users can then Add a record using a button on the Summary form which launches a data entry form (let's call it Data Entry Form #1). From Data Entry Form #1, there is another form that can be launched (Data Entry Form #2) for entering child records about the record being filled out on Data Entry Form #1. There is referential integrity enforced at the table level.
The flow from the Summary Form to Data Entry Form #1 and Data Entry Form #2 is important for the integrity of the data. I have dictated this flow explicitly in VBA and will instruct users to always begin at the Summary Form.
After that lengthy background, my question.....
What are my different options, and the relative advantages/disadvantages for the options for deploying this application to my various sites. My basic requirements are:
Ideally users would never see the tables in which the data is being stored in.
The Summary form would launch when opened and they could not open any other form directly.
Closing the Summary form would close the application.
Since there is a bunch of VBA code dictating important functionality, if they did not accept the Security Warning, they would not be able to access any of the forms or use the tool
I can easily script the extraction/export of the data from the two tables for each tool
I am vaguely aware of the following options:
- Distribute the full ACCDB file to the sites
- Create and distribute an AACDE file to the sites
- Use the Access Developer Extensions to "package" the application - create and EXE file?
I have also read that if users do not have Access 2007 or later, that they can download the MS Access Runtime Services and be able to use my application without having to buy/install a full version of MS Access. Can someone confirm this? Does this apply to all of the above (ACCDB, ACCDE, EXE) Is there any functionality that would not be available to them from a strictly data entry role?
Thanks!
You should be able to do most of this with options set within access, plus some code;
Create an accde;
Using that accde, in the options, untick display navigation pane (or something like that); There should be an option to disable the shift key as well.
Set startform to the summary form
Closing the summary form closes the application: In design view of the summary form (in the accdb, before you do the rest of this), create a form_unload event; In this event put
DoCmd.Quit
More of an issue might be whether or not all the sites have the necessary components of ms office to run access 2007, or if you need to provide an access 2007 runtime as well, but I'm not going there. If you need to do this, you'd best ask another question or go hunting for an existing answer.
Hope this helps
If you do want to package the database as a run-time, the MS tools are notoriously flaky when it comes to deploying. A company called SageKey sell scripts that actually work, dealing with the issue of other versions of Access being installed, and many other things.
I've used about three versions of their scripts (ie. for three different MS Access versions), and they have been great.
I have a MDB database with plenty of VBA code, there are also connection strings to database. I need to have both the connection strings hidden, and the VBA code unavailable. In general I need to disable all functionality that is granted through shift-clicking the database file.
I tried making an MDE but it seemed to have no actual impact even though no errors were thrown, the MDE is exactly as accessible.
Thanks!
In addition to creating an MDE, you can:
disable shift-clicking
hide the database window
(this link shows how to do it manually in the options - it's also possible with VBA, but I can't find an example right now. I can look tomorrow if you're interested)
At work, we have a "publish" process where we create an MDE and do the things linked above.
EDIT:
Creating an MDE is a realistic way to prevent access to the VBA code - MDEs contain no code and you can't edit forms and reports.
The only thing you can do in an MDE is opening the database window and view/edit the tables. But you can kind of prevent that by disabling shift-clicking and hiding the database window (see my links above).
Note that it's still possible to link the tables in another MS Access database and view/edit them. So there's no 100% proof way to secure anything that you put into a table.
But when you put the connection strings into the VBA code and completely remove the code by creating an MDE, it's not possible to get the connection string out of the MDE.
I'm having to do some maintenance on a Access 2007 application. I've never really used it before so I'm struggling to figure out where things are hidden. This application is broken up into two ACCDB's - one for the application, one with the data. Inside of the application I am attempting to track down where various queries are defined but not having much luck.
I've looked in the data ACCDB and selected the "Queries" category off the sidebar. The queries are not there. Inside of the Visual Basic editor of the application ACCDB, they also don't appear in the "Microsoft Office Access Class Objects".
If I click on "Create", then Query Design it seems to open a designer where I can select these queries. However, I still can't seem to figure out how to actually edit existing ones (which is what I really want to do).
Where on earth can I edit them?
On the sidebar on the left you can select different categories like Tables, Queries etc.; however, queries can also be stored in the RecordSource of Forms, Reports and the RowSource of controls. For instance ListBox and ComboBox have a RowSource property. Queries can be stored as SQL strings in VBA code or Macros or they can even be created dynamically with VBA.
Good day...
The root of my issue is that there's no context menu allowing the user to delete a row from a form. The "delete" button on the ribbon is also disabled. In Access 2003, apparently this function was available, but since our recent "upgrade" to 2007 (file is still in MDB format) it's no longer there.
Please keep in mind I'm not an Access dev, nor did I create this app - I inherited support for it. ;) Now for the details, and what I've tried.
The form in question is a subform on a larger form. I've tried turning "AllowDeletes" on on both forms. I've checked the toolbar and ribbon properties on the forms to see if they loaded some custom stuff, but no. I've tried changing the "record locks" to "on edit", no joy. I examined the query to see if it was "too complicated" to permit a delete - as far as I can tell, it's a very simple two (linked) table join. Compared to another form in this app that does permit row deletes, it has a much more complicated (multi-join, built on queries) query.
Is there a resource that would describe the required conditions for allowing deletes?
Thanks in advance...
Open the query that is the basis for the subform. Can you edit a record? If not, the query is probably the problem.
Are you quite sure the change in functionality happened with the 2007 upgrade? Because the next likely cause is a setting, one of many accesses via the form design interface OR in VBA code.