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).
Related
My company hired an outside firm to build a complex program for them through Microsoft Access. The program is designed to link with a second access database, run a series of linear equations in the background, and spit out a few reports. As a user, I interface with a simple GUI in the Access file to 1) tell it which database to link with, 2) manipulate some data, and 3) run reports.
If possible, I would like to see the back end of this program to see the programming logic and to identify how it creates the reports. I am familiar with the basics and the methodologies of Microsoft Access, but don't know much about the dedicated functions of the application.
Thank you for your advice!
The Access / GUI file is actually the front-end, whilst the database you select in the GUI will be the particular back-end you're dealing with. The coding is most likely to be in the front-end as VBA (or as a series of queries, macros & reports).
So, try holding shift when you double-click the Access file, which will try to load the GUI in "design" mode. As #June7 noted though, if its a locked-down / executable mde or accde this won't work, it'll need to be mdb or accdb. You'll also require a full version of MS Access, not just the free runtime installed on your machine.
If you manage to open in design mode, you should be able to see any tables, queries, forms, reports & VBA modules in the navigation pane on the left of the screen... unless of course, they've made them hidden objects. The can be unhidden if this is the case, though.
There may also be password-protection on some parts (which is easily crackable using info you'll find on Google).
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.
In Access 2003 I used to import special xls files provided to us by a third party. I used ADODB for this, which worked perfectly.
ADODB is no longer an option in Access 2007/2010, and I don't think you can "query" a spreadsheet using DAO or ADO.
So, are there any alternatives?
I don't think you can "query" a spreadsheet using DAO or ADO.
You can indeed query an Excel workbook using ADO with the OLE DB provider for Access (Jet, whatever). See this MSDN article for more details.
ADODB is no longer an option in Access 2007/2010,
That is not the case. I think you must have misunderstood something, which is hardly surprising considering there is a lot of nonsense out there on the interwebs surrounding "ADO vs DAO" in Access.
I'm not exactly sure what happened when ADO classic was introduced to the Access2000 community but it seems that a lot of old-timers were left with hurt egos/pride. The marketing message from Microsoft was in effect, "DAO is now the old way of working and ADO is the new." In a deliberate move by MS,, new engine features were generally only available via ADO.
As is often the case when entrench positions are threatened, there was a counter-movement by long time Access+DAO fans. This often took the form of, "throw enough mud and some will stick." People newly arrived in AccessLand would be confused by the mixed messages. In the newsgroups, aspiring Access MVPs emulated existing Access MVPs' anti-ADO stance.
Between the 200 and 2007 releases, the Access product became IMO somewhat stale as regards the engine, responsibility for which had been handed to the SQL Server team, who had for all practical purposes given up on it: their attempts to make it comply with entry-level Standard SQL-92 were thwarted by the Windows team, whose components relied on features that flew in the face of the Standard. The ADO classic team had similarly been disbanded. Visual Basic COM, which effectively shared VBA libraries with the Office suite, was killed off in favour of VB.NET and ADO.NET was born,
The Access2007 team shook things up again. They reclaimed the engine from the SQL Server and Windows teams by taking a private branch. They ditched user level security, presumably because it was too complex for them to maintain. They added multi-valued types that arguably violate 1NF. Brave stuff! While some features could be accommodated in ADO classic by authoring a new OLE DB provider for Access, others could not. For example, full support (e.g. updating via SQL) for multi-valued data types in ADO would require a change to the ADO classic libraries which the Access team does not own.
Because DAO was owned by Access, the new version (called ACEDAO) got features the new OLE DB provider with the old ADO classic libraries would lack (although ADO was required to use the engine on 64 bit machines). However, what they did not do was to retrospectively fix DAO to accommodate the Access2000-era functionality that went into ADO only.
Naturally, the Access team promoted ACEDAO as first class citizen. Of course, the long-time Access+DAO fans were delighted: "ADO has been deprecated in favour of ADO.NET," they crowed. In truth, the net result is a mixed bag. See this thread for full details.
In your VBA project in Access click on Tools / References then find "Microsoft Excel 14.0 Object Library". This will give you access to all of the VBA Excel objects so you can do whatever you want to the spreadsheet.
As others have said running queries on the sheet is not an option. If you're used to thinking in terms of databases think about running a check on the template to make sure the headings match so you more than likely have a good file you're reading from. Then once you've verified the document setup SQL inserts on the lines with records on them into a table in an Access Database then run your queries from there. Check here for writing your SQL code:
SQL Statement Help
If you want to get more advanced in your VBA if your files are small you could run searches by setting up an object with setters/getters and store the records into a collection class then iterate across it with the data you're looking for.
I do this in some projects where I know the lists are small, gets away from reading/writing to tables when I really just want to read the data and run some real basic calculations like count the number of a particular widget and place the count on a report. Collection classes are great for this. Here's a good link for some more info on collections:
Collections in Visual Basic
Good luck!
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 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.