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.
Related
As a preface, please note that this posting is NOT a duplicate question about any of the following common issues with Microsoft.Jet.OLEDB.4.0:
This is NOT the "There is no 64-bit version of Microsoft.Jet.OLEDB.4.0"-problem.
I am running a 32-bit .NET executable on both machines.
Both machines have the 32-bit version of Office 2019 (via Office 365) installed.
This is also NOT the "Using Access/VBA functions inside JET" problem.
Functions like Nz() are only available inside SQL executed inside Access VBA, those functions are not available inside SQL executed through the JET or ACE.
However CLng is a JET intrinsic function that should work when used through JET (i.e. outside of Access VBA).
Problem statement:
I have a SQL query that uses a JET intrinsic function such as CLng(). Below is a minimal query that reproduces the problem:
SELECT
CLNG( 123 ) AS Foo
When I run this query on my computer (with 32-bit Office 2019 via Office 365 installed):
When I use the Microsoft.Jet.OLEDB.4.0 OLE-DB provider it fails with this exception message:
OleDbException Undefined function 'CLNG' in expression.
HResult: -2147217900
NativeError: -530123806
SQLState: 3085
When I use the Microsoft.ACE.OLEDB.16.0 OLE-DB provider it succeeds.
When I run this query on another computer (also with 32-bit Office 2019 via Office 365 installed):
When I use the Microsoft.Jet.OLEDB.4.0 OLE-DB provider it succeeds.
When I use the Microsoft.ACE.OLEDB.16.0 OLE-DB provider it succeeds.
The same database file is used in both computers, it's a JET 4.0 (Access 2000) *.mdb database file.
Both computers report the same information for the JET and ACE drivers when enumerating 32-bit OLE-DB providers (see screenshot below, my computer is on top, the other computer is at the bottom):
I am not testing with Microsoft.ACE.OLEDB.12.0 because ACE 15 (Office 2013) and ACE 16 (Office 2016, Office 2019) both overwrite the ACE 12 provider registration so that any application requesting ACE 12 will get ACE 15 or 16 instead.
Assumptions:
I'm going to assume there's some flag or systemwide switch that configures how Microsoft.Jet.OLEDB.4.0 handles intrinsic functions (I understand that the JET 4.0 driver can run in SQL-89 and SQL-92 modes, I wonder if it's related to that) which doesn't affect the Microsoft.ACE.OLEDB.16.0 driver.
I'll be reaching out to Office support over this incident and report back their answer - if any, but if anyone has any idea I'd greatly appreciate it.
Interesting.
Have you checked the sandbox settings for JET/ACE?
The sandbox settings will prevent use of "some" functions in JET/ACE sql, and prevent (not allow) them to be used.
info here:
https://support.microsoft.com/en-ie/office/turn-sandbox-mode-on-or-off-to-disable-macros-8cc7bad8-38c2-4a7a-a604-43e9a7bbc4fb
https://support.microsoft.com/en-ie/office/functions-and-properties-in-access-blocked-by-sandbox-mode-9a829783-f7a8-4a9f-8d43-8650b8cc9565?ui=en-us&rs=en-ie&ad=ie
However, clng() is NOT one of the blocked sql functions. So I do doubt this would be a issue. But, I would do a quick test/check of these issue. (again, my sorry for suggesting a long shot - based on your given information, this should not be your issue).
Right now, best guess? You want to install a JET sp update on your dev box that fails.
I would try sp8 from here:
https://www.microsoft.com/en-us/download/details.aspx?id=7151
Your writeup seems VERY through. And since queries DO WORK, just not those with some functions. I HAVE seen this issue in the past - and I can't remember the solution. I recall this was around 2003!. We found that "some" functions in sql would work, and some don't. I seem to recall the fix was to re-register a extra .dll that provides jet with SOME additional functions native to jet. In other words there is a .dll that holds/adds/allows some of the JET sql functions. if that part is broken, then SOME jet functions don't work.
Question:
do other JET native functions fail? Or all of them?
If all fail, I would look at sandbox settings. And if some,then sp8 install is a best guess.
And give that this is 100% jet, then issues such as broken references IN regards to VBA does not apply here. And I recall this was NOT VBA functions failing and it was NOT due to broken VBA references. (once they go south, then near all of the sql() functions can break WHEN using Access applications, including JET sql.. (again: you using JET, not really access).
I suppose the other long shot? If this is a different mdb, or a copy that you been beating to death during testing? I would consider launching it with access and do a compact + repair.
The all or just "some" jet sql functions would shed light on this. However, once you find this answer, I don't have a solution! But if ALL functions() fail no matter what? Well, then JET as opposed to ACE is borked on that machine. You need to re-install JET. I not done that since about 2007. (JET is part of windows).
I don't think you can/will find JET for download. But you can google for JET sp packs - so that is my best shot and advice - try installing a JET sp8 pack.
It turns out that on my machine I had earlier done a forced install of the 64-bit ACE driver when the 32-bit ACE driver was already installed. After uninstalling the 64-bit ACE driver (and re-installing the 32-bit ACE driver for good-measure) it started working as-expected again.
I suspect that the 32-bit and 64-bit ACE drivers always delegates JET's built-ins (that aren't in the ODBC-compatible subset) to the Visual Basic runtime DLL which needs to be 32-bit or 64-bit compatible with the ACE driver, but it tries to load it in a way that fails when the 32-bit/64-bit ISA is incorrect (which is trivial to do correctly, I should probably use a tool like ProcMon to see what's really going on...).
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.
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
What are the implications of running a Microsoft Access Database in both 2003 and 2007?
Is there some class I forgot to take?
The program was originally built in office 2003, and then run in 2007. Issues seem to happen when the machine it is being run on has both 2003 and 2007 on it. The issue would also appear to stem from reference from the "Microsoft Access 12.0 Object Library" (or the "Microsoft Access 11.0 Object Library" in 2003). To see this, just look at the Tools: Refrences menu on the VBA screen.
The error's symptom is basically the code not be recognized (almost like it doesn’t recognize the programming language I’m using). It usually follows this with a box that says "The expression On Load you entered as the event property settings produced the following error: Object or class does not support the set of events". You can also replace “On Load” with “On Click” for buttons or “On Change” for text boxes.
I personally suspect that the computer is taking parts of the Microsoft Access 11.0/12.0 Object Library and then mixes the two into a useless VBA reference. What further confirms my suspicion is the box that pops up when going between the two that says "Configuring Microsoft Access" Another issue that further confirms my suspicion is it will run on whichever one it is opened on first (2007, for example) and then not run on the other (2003 continuing the example)
The only other issue is I have had to fix was changing the last part of the DoCmd.OpenForm ,,,,, acFormReadOnly (or acReadOnly, depending on how the machine seems to feel on that particular day - yes it would work with one, one day and then want me to switch it another) to simply locking the individual text boxes
Maybe it’s not quite coding, but I think it might be able to be fixed by coding.
Hopefully that’s enough for someone to come up with something.
Microsoft's official position is that installing multiple office versions on the same pc is not supported and not recommended, and Access 2007 seems to be designed to prove that to us!
That said, you can avoid most issues by doing the following:
1 - Splitting the db into a back end and front end. Place the back end (tables and relationships) in a network folder, and place a copy of the front end (all other objects) on each user's desktop.
2 - It's best to make the front end an mde to avoid the references shuffle every time you open the db in the other version of Access.
3 - Create a shortcut to open the front end with the desired version of Access so it's always opened with that version. (And remember to use the shortcut!) In the shortcut's target:
"path to Access 12 msaccess.exe" "path to db.mdb"
We have an MS-Acces application, developped with Access 2003 and used on either full or runtime version of Access 2003 and Access 2007 (Access 2007 Runtime being free, we are making a great use of it!). There is no particular issue except the references management. Our code analyses the Office version installed on the computer and automatically updates corresponding references (not only Access but also Excel, Outlook, Word, etc.: code is very tricky but of great interest!)
To my own knowledge, no major objects, properties or methods available in Office 2003/VBA were deprecated in Office 2007. Office 2003 code will then run with Access 2007 once these references issues solved. Some new objects were introduced in Office 2007 so I would not advise any developer to use it to develop code to be further used with Access 2003.
But the main & real issue of your question is: why should one run both Access versions on the same computer? This is what I'd do if I want to make sure to crash my apps. I think that if your objectives were to develop software, you should definitely find a better configuration for your machine!
In general, having multiple versions of Access installed on the one machine is unsupported and will result in the issues you are seeing with the object references.
If the database is authored in Access 2003, compiled to an .MDE, and then deployed onto a separate Windows instance running Access 2007, you should not have any significant issues (other than UI changes such as custom toolbars being thrown into the Add-Ins ribbon).
For testing on multiple versions of Access you will need some form of isolation between each version. I use multiple virtual machines to accomplish this. My primary Windows VM runnings Office 2007 and IE7 and I have a second VM which has Office 2003 and IE6 for testing.
Note that if you wish to simply use Word, Excel and Outlook 2007 with Access 2003, you can install Access 2003 first by itself and then do a custom install of Office 2007 and deselect Access 2007.