I'm a small business owner and I'm very new to Access/VBA programming and in trying to protect my Access 2007 database I created a ribbon that restricts users permissions to forms, reports, etc.
Although I gave myself what I thought were the right permissions (as the Admin user in the Admins group) now, when I log into access, the ribbon I created (or some other setting I must have changed) does not allow the "Access Options" button to be displayed when I click the round Office Button so now I'm unable to continue work on designing the forms, queries, reports, etc.
How can I override the ribbon selected before the database actually opens, after entering my login information? or just please explain how can I get the "Access Options" button to display again?
Getting desperate over here, I've watched all the videos I found and read postings to no avail... Help!
Hold Shift when starting the application. It prevents loading forms, ribbons and autoexec macros. Google for "bypass key".
I'd recommend to create at least two ribbon menus: one for development, with system groups and full backstage (File) menu and production, without.
Related
I have an Access 2000 application that a client wants updated to Office 365. The old db has a toolbar that I’d like to use but it appears under “Add-Ins” on the main ribbon. The toolbar works just fine but it’s very awkward and unprofessional to have the user select it from the add-Ins menu. How do it make visible when the db is opened?
Is this still a mdb, or was it converted to accDB (or accDE)?
How big/extensive is the add-in menu? (extensive, or just a few options???).
If just a few options, then you could create a custom ribbon.
A HUGE but BEYOND huge tip? - don't use ribbon call backs. I can expand on this suggestion. But as a general rule the SAME command for the menu can be created and used for the ribbon - and without a call back.
So, right now, about your only option would be to:
Use an access 2000, or 2003 runtime (if you have a copy).
Or consider building a custom ribbon. I mean, a2000? That is 22 years ago.
I have inherited an SSRS environment which is a mess; Folders named only with numbers, hundreds of reports not accessed in the last 2 months (I checked ExecutionLog), etc..
I wanted to achieve two things…
Because every other day someone asks for read access to random reports, is there any way of making it “public”, meaning anyone can read and open ANY report?
I want to revoke “folder/report creation/move” access to everyone; can it be done without going folder by folder?
Related to it, the other day I found another SSRS box, that had this access?! What is that “everyone” is it a group inside my domain, or is it an SSRS feature that you can make it public so anyone can access?
That Everyone group looks like a domain account that your organisation has created. At least, I have never come across it.
To grant access to everyone that has a windows login, you can use NT AUTHORITY\Authenticated Users and set their permission to just Browser which will prevent creation or modification of Folders or Reports.
Regarding removing permissions from your items, your options are to either go item by item or bulk update the ReportServer database, which is not supported by Microsoft. You break something, you're one your own.
A big thing you will need to watch out for with opening up every report to every user is whether or not there is any confidential or sensitive information in any of the reports. Your organisation will not want low level staff looking at executive, cross company summaries nor will HR want their reports visible to anyone other than themselves.
You can export ALL permissions from SSRS using PowerShell.
I've also detailed a script that allows you to revert every folder to "inherit parent security" so you can control every folder by simply setting the home folder security. Sorry for the shameless plug but I blogged about both in April on SQLShack actually Managing SSRS Security using PowerShell
Both scripts are in that post. I hope that helps
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.
Looked around quite a bit before posting this - I just can't seem to get this seemingly very simple question answered (I think I missing something!)
From within MS Access 2007 I have several related tables that deal with inventory of products. I simply want to export that table data into a SharePoint List (or Lists), and link them. Users will generally just use the SP lists in order to search, view, and sometimes modify the data (i.e. mark a product as exhausted). For our work group this is preferential to opening MS Access repetitively.
The problem I'm having is that the linking features within Access don't make sense to me! I seem to be missing something fundamental here, despite reading over the MS documentation and various sources.
One can export a table, but there is no linkage between the created list and the original table. Changes made on the SP list will not be reflected in the original table which makes this a lot less useful?
One can import a list, but that linked table that is generated is NOT the original data table that I started with (the new, generated SP-linked table is a different entity than the original table. Updates to that new SP-linked table are not reflected in any original table that I had). This method seems very backwards, as you ought to have your relational DB setup correctly before attempting to make SP lists that surface that data. It seems backwards to me to make SP lists that are then wedged into an existing DB without any consideration to the existing DB structure?
So - I think that there is something fundamental that I'm missing here. It would seem that one ought to be able to just use SP to surface/provide views/editing of existing Access tables.
Isn't there just a simple way to have a SP list directly linked to an existing Access table, so that changes in the SP list are reflected in the original Access table?
I believe the solution you're looking for is the ability to "Publish" an Access DB to a SharePoint site. If you're using SharePoint 2007, the published copy will be read-only in SharePoint but users can still do everything else you described.
Details on this type of Publish are in the Office Help here:
https://support.office.com/en-us/article/Publish-a-database-to-a-SharePoint-site-8287ed04-9c65-46c4-bbdb-c965c56b018c
To quote from it:
Click the Microsoft Office Button Office button image , point to
Publish , and then click Document Management Server.
Type the URL of
the SharePoint site where you want to publish the database. If you
used the same location the last time you opened Access, the database
appears in the Publish to Web Server dialog box.
NOTE: This option is available only if your database is saved in Office Access 2007 format.
Select the library, such as a document library, where you
want to publish the database, and then click Open.
In the Name box,
type a file name for your database.
Click Publish.
If you have SharePoint 2010 or newer, users in SharePoint can have full CRUD (Create, Read, Update & Delete) capabilities to both the data and even the DB design without having to touch Access once the DB has been published. This is described in more detail here:
https://support.office.com/en-us/article/Build-and-publish-an-Access-database-to-SharePoint-e68bf007-410c-43b2-bf21-322ddbcf5411
The steps to do so are simply:
Open the Access file
Click 'Save and Publish' in the File menu
Choose 'Publish to Access Services' under the Publish heading
Specify the URL to the SharePoint site you wish to publish it to
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.