I have a MS Access database with a table Test on drive X.
On drive Y I have another MS Access database with two queries querying table Test.
For this, I created a link to the Test table.
On top of the two queries I have two forms for the user to edit table Test.
One form only displays parts of table Test in a read-only mode.
With the other form the users can manipulate some of the data in table Test.
So far so good. However, in MS Access the user can see table Test in the sidebar all Access-objects. Thus, the user can open the original table by clicking on the linked table Test.
What I am trying to do is to somehow protect or hide this link to table Test so that the users can only manipulate this table via the forms. Is that somehow possible?
Depends on what version of MS Access you have but you can also do things like in the Tools start up menu deselect
Display Database Window
Note however you need to ensure that your application has a nice flow through and that users do not actually need to see things like the form names to navigate the application.
I.e navigation of forms should purely through command buttons on forms.
If you make this change and you are needing to see the window again hold shift down while opening the database and you will see the database window again.
This worked in Access 2003 and I'm pretty sure its available in other versions.
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.
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.
I am in the process of moving several Access databases into a SQL 2008 R2 server using Access 2007 Projects as the frontends and we're running into problems when users are trying to filter data from the forms.
Example:
I have one project file setup so that the users can search customer data and I'm using a login to the server that only has "CONNECT" and "SELECT" rights so they can't change any of the data. The only form in this project has it's record source set directly to the table, no views or queries. If a user selects the "Customer#" and then presses the "Filter" button, selects "Text Filter" and enters a customer number they get an "Enter a valid value" error (same thing happens if they select a field on the form and right click and try to set a filter). If the user uses the "Advanced/Filter By Form" there's no problems.
There are no other filters set on the form or in code, no input validations, just a plan form.
Anyone have any ideas where to start on debugging this?
Thanks.
At first, you need to confirm that it is a MSSQL permission issue. To check this - try the same with MSSQL user that doesn't have any permission restrictions. Then, you can use MSSQL profiler to look at what actual MSSQL statements are being sent by Access. I beleive that it is not the simple "SELECT", but it will be some system stored procedures calls (that's how Access works with MSSQL). Look at this trace and try to understand permissions that should be added. If your Access application works on the tables level, then may be it would be easier to deny update/delete instead of granting select only - not sure that it will help, but it's just an idea what you can try.
In Access 2003 I was easily able to get to all the tables and edit/view data directly. However, in 2007, I'm unable to find this functionality. I have an MDB with a form, and I can only view the main table of user input data in the Datasheet View.
I'm trying to copy a list of options (there's a lot of them) set to a Combo Box into another program, and it would be easier if I could just get to the Control Source table.
You should be able to see the access objects (tables, queries, macros, forms) in the Navigation Pane on the left side of the screen. It may be hidden in that .mdb, though. If you create a new .mdb and a couple of tables, can you see them?
The UI's a little different and it takes some getting used to.