I've got a MS Access database with a table and a form, but I want the user to only see the form. I don't want them to be able to edit any of the data. The user should only be able to use the form to query the table. Any suggestions??
There are a few ways to enforce some control over what users can do.
AutoExec
The most simple way is to use an AutoExec macro to initialise the user interface when the application starts.
That way to can make sure that only the form you want is displayed and hide everything else.
Runtime
A good complement to this approach is to compile your application and force the user to use the Access Runtime to use your application.
In the runtime, users don't have access to all the standard tools unless you explicitly code for it.
A good thing to know is that unlike previous versions, the Access 2007 Runtime is free, and that makes Access a very cheap platform to develop for.
Runtime emulation
With Access 2007, a simple way to ensure that the application will open as if only the runtime was installed is to change the extension of the database to .accdr.
You can also force a full Access installation to open a normal database in Runtime emulation by passing the /runtime command line switch.
Secure data-access
Note that short of encrypting the database (but then you have to manage the password), all you can do is make it hard for the user to open the tables manually.
A determined and knowledgeable user can always circumvent these protective measures and access the data.
If you need a really secure solution though, Access may not be the best choice: implementing fine grained security in Access is a greater challenge than the alternatives, say storing the data into a SQL Server database for instance where security is enforced.
Links to resources
Security Considerations and Guidance for Access 2007 on MSDN
A simple Microsoft Access User-Level Security Tutorial for older versions of Access.
FormSafe, a commercial product that helps enforce security on form controls.
I believe you want to use Access User-Level Security. Here's the documentation at Microsoft.
If you are using Access 2003 or earlier, you can use user level security, as mentioned. If you are using Access 2007 you are out of luck - Microsoft in their wisdom removed this ability. You will basically have to write your own login and set permissions on editing etc. using VBA code.
Related
I have a Access 2003 and lower databases. The company i work for is currently using MS Office 2007 and Access 2003 instead of Access 2007 because of issues with library references. We're currently converting the Access 2003 databases to Access 2007, but some users are already being upgraded to MS Office 2013 and Access 2013.
I am aware that Access will only change library references when design changes are made in Access 2013 which is not something we want because it will cause issues for users still using Access 2007.
My question is what constitutes a design change? For example we have some forms who's labels change based on user selection, would that be considered a design change? We do not want Access 2013 users to inadvertently make design changes.
The only way to avoid users making inadvertent changes would be to either use the Runtime instead of a full version of Access on their machine or force the database to open in Runtime mode by changing the your front-end's database extension to accdr.
Now, if your aplication relies on the standard office references, you should be ok (for most of them) as Access will use the right one for the version you have.
Any any rate, the fact that you are worried about users making inadvertent modification seems to imply that your users are sharing a front-end, which is not the recommended way to deploy an Access application: the application should be split.
Database containing the shared tables of the application remain on a network share. The Front-end, containing the UI and business code, should be deployed on the local machine of each user. The front-end only contain links to the tables in the backend.
This is a safe multi-user design since only data is shared, not the UI state.
Now if you have that design, if would not matter too much if users made accidental updates since that would only be local to their machine.
In that configuration, you can also keep sharing a specific mdb database with various front-ends for Access 2003, 2007, 2013 being deployed for different users.
Deployment is the hard part since you want that to happen automatically when there is a new version of the front-end available. There are tools like Auto FE Updater that can help.
My boss fancies himself an IT genius, and has created a number of databases, all secured with Access' user-level security MDW feature. Now for the MDW feature to work, you either have to craft shortcuts that point to the MDW, or you have to configure the workstation to use that MDW as default.
He chose the latter.
Now, when opening MY unsecured DBs, or even trying to create new blank ones, it wants me to login to his MDW. This cannot stand.
How can I reconfigure Access to use the default MDW (I think it is called System.MDW).
NB: I cannot run code in the VB window. I cannot open any databases at all. Solutions must likely be external to Access.
Okay, as it turns out, you need to modify the value HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Access Connectivity Engine\Engines\SystemDB to "%appdata%\Microsoft\Access\System.mdw"
Or, in the case of Office 2010, HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Access Connectivity Engine\Engines\SystemDB
Not sure why I didn't look in the registry first.
I have a website online with just HTML and I am not willing to use any other programming language apart from Javascript. All I need to do is connect my Microsoft Access database on my computer to a form hosted online so when information is submitted online it is updated on MS access the next time I open the file up. Is this possible and how can it be done?
Turns out, you can do this with zero code. If you use office 365, and publish an Access web forms.
Any information entered into the Access web form will automatic appear in your local database. The synchronizing of data from the web site and pulling down of the records to a local copy works automatic and without the need to write any code. In fact the sync starts automatic when you launch the client application. (it runs in disconnected mode). And any records you enter in the client application will also sync up and appear on the web site.
So, you can use Access and write zero code, and this two way sync feature is built in.
You need Access 2010, and either SharePoint 2010 (enterprise), or you can use office 365 and the $6 per month p1 plan which also does support Access web publishing.
However, I suspect issues of user logons and security may well be a greater issue here, and thus office 365 might not be correct from a user logon point of view. You can invite up to 50 users to that site for the basic $6 per month, but all users of the site will require a logon (which can be due to being invited to the site).
There are two videos of mine here showing this setup in action here:
http://www.youtube.com/playlist?list=PL27E956A1537FE1C5&feature=plcp
I think what you are trying to do is very impractical. You'll need to use Server Side Javascript to insert your data into a database, preferably SQL Server, and then you'll have to write some kind of code to sync the SQL Server Database to your Access database.
Alternately, you could setup your Access database so it connects to the same instance of SQL Server as your website using ODBC linked tables or ADO. I cannot really recommend this, especially if the data you have in your Access database is anything you wouldn't want to be public. Also, using MS Access to access a database across the WAN/Internet is really not recommended although it can certainly be done, as long as you aren't working with large amounts of data, large quantity of records, etc.
I am not willing to use any other programming language apart from Javascript.
And why aren't you willing to use something else? I don't think you're going to get anywhere if you don't open your mind to using the right tools for the right job.
Here's something that might help you get connected to SQL from Javascript:
How to connect to SQL Server database from JavaScript in the browser?
Is there a way to version the VBA modules inside an Access 2007 database, or am I just stuck with exporting the code and keeping it separate from the database and maintaining two different copies?
MS Access has a MSSCCI interface which you can connect to any source control system which has a MSSCCI interface. Many of them do. For example for SVN there is AgentSVN or VisualSVN.
Download and install the Access 2007 Developer Extensions, and choose the source code control from your installed SCC providers.
Source control in MS Access uses the Access SaveAsText/LoadFromText methods. All recent versions of Access use a VBA object to hold the VBA modules in, they aren't stored natively in the database anymore, so you can't just export the record holding each module as you used to be able to do.
There are mixed reports about using integrated source control in MS Access. Your milage may vary.
On a historical note, a multi-user, multi-process relational database is ideal for ensuring coherance in source code. According to some reports, the Office 2000 developers were unable to maintain project coherence when using the native database to store modules, and fixed it by using a locked single project object. Possibly missing the fact that Windows 2000 SMB server was corrupting data (fixed in Win2K SP1).
Based on the response so far, I conclude you can't have versioning.
I believe this is because an Access DB code-base is not viewed as a set of modules -- that is, not as interchangeable elements the way code is in many other settings. A truly modular approach increases the requirement for strict control because you must ensure coherence; thus, versioning.
Code in VBA is not handled as agile -- which of course is understandable historically. It's a huge watershed in development approach. So while you benefit from an agile mindset, you won't find it facilitated so well.
NOTE:
In case you're not aware, some key aspects of modular approach are met by separating the app into client and server documents (splitting your database).
I am writing a C++/MFC application that will use Microsoft Access to store data.
I hope using it will suit my purpose : small, lightweight way to keep application's data.
the question i'm asking myself is : if I use Access as DB, will the client's machine be required to install Microsoft Access to use my software ?
thanks.
Do you simply want to use Access files (*.mdb), or do you want to embed the Access Active Object in your application?
If you just want to use its file format, they just need to install the ODBC drivers, not the entire application.
But if you want to use ActiveX to embed Access UI inside your application, they need to have full Access installed.
Going by the Microsoft Data Access Components page on Wikipedia, it states in the table that from the initial release of Windows 2000, ODBC drivers for Microsoft Access are included by default. In other words, you should be safe to assume that your program should have no problems reading MS Access databases on any Windows PC nowadays.
The problem here is the promiscuous use of "Access" to mean "Jet MDB." If you've got an Access database, it's an Access application, with UI objects (forms/reports/etc.) and to run it you must have Access or the Access runtime installed.
It's pretty clear, though, that you're just using a Jet MDB to store your data, in which case everything you need is already installed on every version of Windows from 2000 on because Jet is installed as part of the OS.
Francis is correct, however you might want to take a look at more robust DB choices. SQLite, SQL Server Compact Edition, or Firebird are all good alternatives to MS Access for simple, light-weight, easy RDBMS needs.
You don't need Access to use a an Access database - you can use ODBC for that. However, if you are also considering XML, I suggest you have not analysed the problem you are trying to solve deeply enough - XML and databases like Access have almost nothing in common.