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!
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 am making an Access app that will be using Jet exclusively(No SQL Server), and split into front end back end architecture. I have weighed the pros and cons of bound/unbound, and still would like to pursue unbound in this situation.
I have a handful of classes and modules I will be importing into this project which rely on ADO record sets. However, I have read several indications which suggest using DAO to populate Access forms http://support.microsoft.com/kb/281998 {Requirements for Microsoft Jet} . I know that these are totally different libraries, and cannot share info from one another. However, I was thinking that my classes and other ADO dependent objects could use a mix of local tables/queries and form control values which would avoid a potential collision.
So my question: If I only us DAO to fill forms in this project, am I still asking for trouble? If so, what kind of problems should I be aware of? Or is it reasonable to expect that this separation could co-exist if I am careful, and the distinction is explained in the apps documentation?
Mixing DAO and ADO in the same application doesn't really present any problems or complications. I think your question really has a lot more to do with when and why would you use one or the other.
My own standard policy in Access development has been to use ADO only when DAO won't work for something I want to do. For example, with ADO you can access data stores other than Access such as Visual Foxpro, Oracle, MySQL, etc. But ADO isn't always required to achieve this either since you can often use ODBC instead, which means you would then be using DAO together with ODBC linked tables.
Recently I have somewhat switched gears to where I prefer to use ADO exclusively, but I recognize that this is not the common practice among many experienced Access developers. I'm using SQL Server 2008/2012 Express and forms bound to ADO recordsets, and I'm avoiding using any ODBC linked tables at all. My basic reason is that ADO gives me a few more options and more control, although it does come with it's costs. I use a lot of disconnected recordsets and then I "manually" (VBA) write the changes back to the database only if the user clicks the save button. This gives the user the option to make a bunch of changes to a form and it's subforms, but still cancel out if he chooses. With disconnected ADO recordsets it's up to you to determine how to get data changes to the server, although non-disconnected recordsets automatically submit their changes. As near as I can tell, the only ADO recordset type that automatically receives all additions, changes, and deletions from the server (adOpenDynamic) cannot be bound to a form, but that's really not a huge concern if you just want to be able to use ADO bound forms for adding/editing/deleting records.
I've read numerous places that ADO doesn't have any performance advantages over DAO, and in some cases may actually be slower. I cannot say one way or the other, but I don't think this is a big concern. ADO has the advantage that you can actually make your application work across slow and/or unstable network connections (such as WAN/Internet), which is really not feasible with DAO/ODBC. With a pure ADO solution, you are in charge of handling the connection object and all fetches of data. You can set the connection and command timeouts and if the timeouts occur, the connection fails, etc., it's up to you to decide how to handle it. You could, for example, make X number of reconnection attempts. None of this is really possible in DAO/ODBC. As far as I know, the connection object isn't even exposed with ODBC, other than the fact that you can setup the ODBC connection string.
It does take a lot more code to do everything in ADO, particularly if you want to use disconnected recordsets. Recordsets have to be fetched (or fabricated) using code. If you use disconnected recordsets, data has to be written back to the server using code. Whether you use disconnected or connected recordsets, Master/Child relationships on forms have to be manually managed using code (you can't use the Master/Child Link properties).
One potential downside with ADO is that it isn't possible to bind a report to an ADO recordset unless you are using an Access Data Project, which isn't really recommended at this point, seeing that MS is dropping support for ADP's. If you want to use something other than DAO for data on a report, you would have to use Pass Through Queries, and if your data store is MS Access it would make no sense to do that.
I think any discussion about bound and unbound forms is completely unrelated to any discussion about DAO and ADO. Forms can be bound to ADO Recordsets with very few trade-offs. An unbound form could get it's data from a DAO Recordset or ADO Recordset and there would be no difference so unbound forms and ADO are no more related or unrelated to each other than DAO and unbound forms. I really only use unbound forms for creating my own Message Boxes and certain kinds of input boxes or record selection boxes. Usually it's a case where I want data displayed on buttons for a touch screen application and then I go unbound. If I could get similar behavior from Textboxes (and I probably could if I tried hard enough), there would be few cases where an unbound form would be necessary.
It seems to me there has been an idea propagated that unbound forms are the way real professionals develop Access applications. Or that unbound forms are the only way that you get performance. Or that unbound forms should be used if you're not using MS Access as your data store. But none of these ideas really hold up to any scrutiny. Binding forms to ADO recordsets is much easier than going completely unbound. And it's not even possible to use Datasheet Views or Continuous Forms in an unbound manner. If you really want to go unbound in a grid-style view you'd have to use an ActiveX grid control such as iGrid from 10tec, or the MS List View control which usually have more overhead since there is the time needed to fetch the Records and the additional time needed to fill out the grid controls with the data. An unbound form has no performance gains that I can think of over binding the form to an ADO recordset. And there's really no kind of data store that can't use an ADO Recordset, even if you have to use a fabricated ADO recordset.
This is a tremendous oversimplification but your primary performance gains in MS Access come from maximizing the performance of your data store (which usually means moving to SQL Server) and carefully managing how much data you load and present to the user. The easiest way to do the latter is with ADO, but you can also do it with DAO/ODBC as well. ODBC actually has one advantage over ADO, called lazy loading. You can bind a datasheet form or continuous subform to a very large table/DAO recordset and the loading of each record will occur as you scroll. Its a feature I'm not very fond of and I've had users complain about it since you don't get to see the records until you release the scroll bar, but I'd have to argue that it is one of the most efficient ways of handling large amounts of data (> 50,000 records).
There's a fairly extensive article on the UtterAccess Wiki that details the pros and cons of DAO versus ADO (Note that the article got deleted and the only way to view it is the look at the history of what was at one time. Just make sure you scroll down below the diff/comparison). And there's another great article on unbound forms at AccessExperts.com written by Juan Soto.
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).
Does anyone know of a way to make Excel 2003 push changes to a MySQL database?
Currently, we're using Excel 2003 for keeping track of a big bunch of interconnected equipment (actually, an entire electric power distribution system with all the hoo-ha's that hang off it.) Quite frankly, using a spreadsheet for this sucks and I'm sick of it, so I want to convert it over to a Real Database like MySQL.
The gotchas are:
The people who are using it aren't overly computer savvy. Using Excel to edit the MySQL database saves them the pain of learning something new.
We don't have a license for MS Access, or I'd use that instead.
I don't have the time to roll my own custom app.
I've already grabbed the MySQL ODBC driver and installed it, and importing data from MySQL to Excel is a breeze; but there's no obvious way to to the reverse, and push changes in Excel back to MySQL.
There are (at least) two possible approaches here.
Use a MySQL database and, as you suggested, use the ODBC driver to update the database. Using ActiveX Data Objects (ADO) can let you accomplish this. See here for details
Alternatively, you can create a Microsoft JET database and use that instead of MySQL. This can be done using ADOX to create the database - see here - and then ADO to update it.
Both ADO and ADOX are available on my standard Office 2003 install (which does not include Access) so hopefully your system will have them too.
As a fallback if these aren't available, you could look at Data Access Objects (DAO) - the predecessor to ADO - but ADO seems a lot easier to use to me. DAO details are here
#Roland Bourman's comment (which would deserve to be an answer in itself) is a very interesting approach. If you're not a VB expert, you could mabye even do the pull/push outside of Excel on script level, pulling the data from mySQL into an excel sheet before opening Excel (easy) and writing it back after closing it. This could be done using a variety of tools.
The scenario in question relates to the much-maligned Microsoft Jet database engine. The assertion was that the Data Access Objects (DAO) data access technology is 'native' to Jet, the implication being that creating an object via the DAO model is 'superior' to doing the same via SQL code executed from within in the Microsoft Access user interface.
Furthermore, it was asserted that if you couldn't create something via DAO then by definition it is not 'native' to Jet.
To me, this definition of 'native' seems to be misplaced. There are a number of Jet objects which, for historical and Microsoft political reasons, were omitted from or only partially implemented in DAO (CHECK constraints, fixed-width data types, the DECIMAL data type, compressible data types, etc) but were included in Jet's SQL data definition language (DDL). Intuition alone tells me that Jet SQL DDL should be considered 'native' to the Jet engine.
So my question is: why would a technology seemingly external (DAO) be considered 'native' and another technology seemingly internal (SQL DDL) be considered 'non-native'? Should I be troubling myself over whether something is 'native' or otherwise?
This question is not really posted in good faith, in my opinion -- it's entirely directed at me and the comments I've been making in reponse to your comments. I've already answered all the issues elsewhere, but just to make things clear, let me outline the history of Jet.
Jet was introduced in the early 90s along with Access. Between version 1 and 2, MS acquired Foxpro and incorporated its "Rushmore" technology into Jet. Somewhere along this time frame, MS developed DAO as the interface layer to Jet. I don't know for a fact that DAO ever had an existence as anything other than a data interface layer that used Jet for all data access, but that's how it looked to me. Jet was a rather good choice for this since with ODBC and installable ISAMs, it could make just about any of the then-common database formats look and behave in your app in the same way native Jet data looked and behaved. Back in those days, the desktop database market was dominated by dBase and its variants and Paradox. These were all desktop db engines, not server databases. Access to server databases was generally through ODBC, but was not at that time all that important to desktop db application developers. Jet managed fairly well to connect to ODBC data sources and utilize them pretty efficiently, though it would sometimes make mistakes (and this is why ODBCDirect was introduced into Jet, which would bypass certain aspects of Jet's data processing engine).
Now, parallel to the rise of Access/Jet/DAO, Visual Basic was the hot product for generalized Windows app development and before the flourishing of the Web, VB was the most widely-used programming languages in the world. DAO and Jet provided VB developers with an interface to all sorts of data stores, and the VB development tools were well-integrated with them. Thus, after ODBC, DAO became MS's key data interface layer, utilizing the Jet engine to work with all kinds of data.
Naturally, this had its problems and was also very limiting in that Jet/DAO (and VB) were all desktop-oriented tools. By the mid-to-late 90s MS was attempting to expand from a provider of desktop softwares, desktop OS's and development tools to an enterprise software provider. So, MS needed to develop more robust data interfaces, something like ODBC for database servers, but with all the modern features that newer server databases offered. OLEDB was the answer for this with ADO as the interface layer on top of OLEDB (just as DAO is the interface layer on top of Jet). While the goal of DAO was to provide access to lots of data stores via the Jet database engine, OLEDB was a more neutral data interface layer like ODBC, a database abstraction layer, and ADO was the interface to that neutral data interface layer.
On the question of "native" DDL, it is a fact that before Jet 4 there was very poor support for SQL DDL. That is, there were features of Jet that were not controllable via SQL DDL. Instead, you had to use DAO to control those features. While the Jet Database Engine Programmer's certainly includes DDL examples alongside the DAO examples, the DAO examples are able to do a lot more because the Jet DDL SQL never supported all the features of Jet databases.
The breakdown that seems to be so confusing came about because of internal MS politics. By 1999, when MS introduced Access 2000 (with the new version of Jet, 4.0), MS wanted to retire DAO in favor of ADO. MS made ADO the default data interface layer in Access even when it made no sense to use ADO (i.e., your data store was Jet). As part of this effort, MS did not fully update DAO to incorporate support for all the new features of Jet 4 -- instead they put their efforts on this front into ADO. The result was that Jet's native data interface layer, DAO, lacked support for Jet features that the database neutral interface layer, ADO, offered. This was, in my opinion, a particular form of douchebaggery on Microsoft's part. MS was intentionally not updating Jet's native interface layer in order to force you into using the non-native interface. So, instead of DAO->Jet, you had to use ADO->OLEDB->Jet, even to for some things that were native aspects of the Jet database engine (such as some data types for fields).
Microsoft's goal was to kill off DAO entirely, and really, to kill off Jet itself. They wanted customers to move to SQL Server.
But a number of things happened. For one, ADO, which was COM-based, could not fit in very well with .NET, and therefore, classic COM-based ADO ended up being abandoned and ADO.NET created to take its place. The resemblences between ADO and ADO.NET are quite superficial and are based on completely different models of data interaction, with ADO.NET being almost entirely designed around the idea of disconnected data, while ADO was not (though it certainly supported certain kinds of disconnected data access).
With ADO going out the window, MS had a hole in the middle of its product line. The classic VB developer or Access developer was not going to see much benefit in .NET, because the whole data access model didn't fit. Thus, by the release of Access 2002, MS had reversed course and put DAO back in its place as the default data interface layer for Jet data (and all the other data stores Jet could work with via, e.g., ODBC, etc.). Unfortunately, while MS was now deprecating ADO for use with Jet, they didn't choose to fix the crippled version of DAO that went with it. Perhaps they didn't do this because by this point the decision had been made to fork the existing Jet 4 into a database engine owned by the Access development group. This eventually became the ACE and is, for all intents and purposes, Jet 4.5. A new version of DAO was released (though disguised a bit with its user-friendly name being "Microsoft Office 12.0 Access database engine Object Library" while the DLL name is now ACEDAO.DLL). I don't know the degree to which the features missing in DAO 3.6 (the Jet 4 version) have been added to the ACE version of DAO. I don't know because I don't need any of those features so don't even know what they are.
In any event, at this point, there is now ongoing development on Jet (we'd been promised that Jet 4 was the end) and on the data interface layer native to it (DAO, which we'd also been promised was dead). This ongoing development is now within the Access application group at Microsoft (as opposed to Windows, where Jet 4 was previously being maintained).
Microsoft has added compatibility modes in Access to use what they call ANSI-92 SQL mode. This is supposed to allow you to write SQL that is "compatible" with SQL Server's SQL dialect. Well, it supports a few things (you can use the SQL Server wildcards and use () for derived tables instead of Jet's screwy []. As Alias), but isn't very close to TSQL. But outside of Access, the only way to use this "ANSI-92" SQL mode is to use ADO to connect to Jet. DAO itself still uses Jet's old dialect of SQL. This shows that Jet is not providing support for this mode itself, but it's being provided by layers above Jet.
Maybe I'm wrong here, but I always understood it like this:
the MS Jet database engine is by all means a database engine (underpowered or not)
it's "native" interface to the outside world is an SQL dialect
whereas:
DAO is one of Microsoft's database abstraction layers, designed for use in a COM environment like VBA or Windows scripting
it was developed with Access (which can be looked at as a user interface / reporting tool for MS Jet, since MS Jet can exist without MS Access), and is strongly bundled with both MS Jet and MS Access, nevertheless it is in the same category where ADO would be in