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.
Related
we have an over the years grown Access Database which is making use of a Treeview Element and the Excel Office reference. With some Windows Updates we ran into problems with the Treeview (throws random errors about ActiveX control for each input: mouse move, mouse click, etc.).
Some customers use Access 2003 (we 2007) and therefore some errors are thrown on the first time opening the database because the references have to be adjusted.
I want to solve those problems by taking the office 2003 reference (I think it should be the MSO.dll) and store it in the database as an OLE object. On Startup I want to 'extract' the file and use it as a reference for the office libraries, so that I am kind of independent from the installed Office version on the machine.
Furthermore I thought about doing the same thing with the MSCOMCTL.OCX so that it can not get corrupted from Windows Updates anymore. I hope to gain more stability in the application.
My questions would be: Is it possible at all to use the office references from a local file instead of the windows dir?
And is it possible to use an ActiveX control directly from a local file instead of the registered one through RegSvr32?
If so, any links or information how to achieve this will be greatly appreciated.
Kind regards,
Matthias
I honestly don't know if it's possible, but I certainly would do everything I could to avoid going down that road. The potential for even worse stability problems and general weirdness would be significant. I would push for either
standardizing on an Office version (not 2003), or
using a third-party treeview control from a reputable developer and using late binding to replace the Excel reference(s).
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've currently been using Base/MS Access to create forms etc. that interface with a backend database, to save me writing a backend in PHP. Downside is that it only runs on the desktop. Is anyone aware of any web-based equivalent?
Edit: Should have done more research, I need it to interact with MySQL, not an Access DB.
Have you considered Access 2010 : Hosting an Access DB
Depending on Access version, you could use Data Access Pages (Can be used with Access 2007+ with some additional work.). The recommended usage for 2007+ would be within SharePoint.
As the title says, I would like to use Vault for source control of an MS Access application that contains forms, queries and modules with vb code. I want to avoid the tedious process of exporting and importing modules to and from text files for the purpose of diffing with previous code.
Thanks.
Access 2003 does work with Visual SourceSafe 6.0.
I have to assume since access does have support for SCC, then perhaps it is a standard interface? I don’t believe SCC for ms-access will work with SourceGear.
You can find info on using VSS 6 with ms-access here:
http://support.microsoft.com/kb/837136/en-us
I used SCC with ms-access. You can even check-in/check out forms or even queries. So, it does allow more then one developer to work on the application at the same time.
Keep in mind the above SCC for ms-access works by using the un-documented
Saveastext
And the reverse is:
LoadFromText
Type the above two commands in the access debug window, it will give you inteli-sense as to what the options + parameters are.
With the above information you certainly could import + export bits and pieces in and out of ms-access into Source Gear.
So it is a bit of a long shot to get SCC feature of ms-access working with Soruce Gear, but you could cobble together something that pulls objects in and out of Source Gear by using the above two commands.
The only thing I can add to Albert Kallal's answer is that I actually did use MS Access with two different source control providers - with MS Visual SourceSafe and with SourceGear's SourceOffSite.
There were some occassional problems when our team was using SourceOffSite - like sudden failures of MS Access during some source control operations - but all in all it worked. (Perhaps those problems were caused by the fact that we sometimes "mixed" those two source control providers - i.e. one developer was using VSS and another was using SOS. So I can't really blame those problems on MS Access itself.)
Now, I never used Vault. But, since SourceOffsite and Vault come from the same vendor, I think there is a very good chance that (a) SourceGear offers an MSSCCI provider for Vault and (b) MS Access can be used with Vault successfully.
Hope this helps.
I haven't tried earlier versions, but I can confirm that SourceGear Vault 5.0.4 can be used with Microsoft Access 2003 (with the Access 2003 Add-in: Source Code Control installed).
For this to work, you need to enable a option in Vault Client called "Make Vault your default SCC provider".
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.