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
Related
It has been a good number of years since I did some programming with Classic ASP and Microsoft Access where we used "Microsoft.Jet.Oledb" driver to access and display the data.
I have been asked to do some work with accessing MS Excel data using "Microsoft.Ace.Oledb". I have found this to be part of the "Microsoft Access 2010 Engine Redistributable" download.
I would like to know if "Microsoft.Jet.OleDb" has replaced "Microsoft.Ace.Oledb" driver and are essentially the same or are they completely different things?
Also, do you normally get the "Microsoft.Ace.Oledb" driver when you buy MS Access 2010?
It's mainly a matter of history, effectively ACE has superceded JET:
Wikipedia answers your question in great detail.
The most relevant sections are:
With version 2007 onwards, Access includes an Office-specific version
of Jet, initially called the Office Access Connectivity Engine (ACE),
but which is now called the Access Database Engine. This engine is
fully backward-compatible with previous versions of the Jet engine, so
it reads and writes (.mdb) files from earlier Access versions. It
introduces a new default file format, (.accdb), that brings several
improvements to Access, including complex data types such as
multivalue fields, the attachment data type and history tracking in
memo fields. It also brings security and encryption improvements and
enables integration with Microsoft Windows SharePoint Services 3.0 and
Microsoft Office Outlook 2007
In addition, ACE provides a 64-bit driver, so can be used on 64-bit machines, whereas JET cannot.
The driver is not part of the Windows operating system, but is
available as a redistributable.[11] Previously the Jet Database Engine
was only 32-bit and did not run natively under 64-bit versions of
Windows.
As for the second part of your question, I recently installed Office 2010, and I had to download the ACE components separately. I got them from the link Microsoft Access Database Engine 2010 Redistributable. This is likely because I had installed a 32-bit version of Office under 64-bit Windows; in any case, the necessary files are easy to obtain from Microsoft.
The drivers are essentially the same when used for basic operations, and show notable difference with more complex stuff (unions, nested queries, etc).
Based on personal experience, ACE does not provide fully backward compatible results. It may open and read/write the previous .mdb format but there are changes in data type casting of exactly the same queries.
For example, when using UNION on TEXT fields, where JET used to return TEXT(255) result, ACE returns MEMO ?!
This can produce a lot of trouble in combination with BI or reporting tools like Crystal Reports.
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!
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 recently started a project where I was set to build an ADP based application in Access 2003. The font end GUI was going to be in Access while all the data resided in MS SQL Server. I say "was", because the powers that be have decided that Oracle Forms might be a better choice than Access and SQL Server. The place where I am doing this work is an Oracle shop where they use Oracle 10g. They also use Oracle Forms quite a bit internally.
As for me I am always up for learning anything new. I have always been a rather "eclectic" developer (I work with .NET WinForms, ASP.NET, Java, C#, Python, and Access) so I would not mind moving to Oracle Forms as long as it could do the same things as MS Access (hopefully even more as VBA is rather limited).
So my question is this. How does Oracle Forms (10g) compare to MS Access for developing a GUI application? Access uses VBA for it's language, what does Oracle Forms use? I know the Forms app is a Java applet. Does that means you can write Oracle Forms using Java?
How does Oracle Forms (10g) compare to MS Access for developing a GUI application?
If you're accessing an Oracle database, I'd prefer Forms. Even better, I'd go for Apex. But that's probably partly because I'm used to these environments. I hated trying to build anything more than the simplest UIs in Access.
Access uses VBA for it's language, what does Oracle Forms use?
PL/SQL
I know the Forms app is a Java applet. Does that means you can write Oracle Forms using Java?
You can incorporate Java beans if you need specific custom components, but normally you don't need to. All your business logic you would normally code in SQL or PL/SQL, either in the form or on the database.
If you were going with an Access ADP, why not go with an Access MDB with ODBC? This has been MS's recommended setup even for apps using SQL Server (except for reporting, where ADPs have some advantages) for about the last 5 years or so.
ADPs are on the way out, it seems, not having had any changes/fixes in the last two versions of Access (A2007/A2010). They always seemed to me to be rather half-baked, but then I was comparing them to a mature platform, their sibling MDBs.
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.