I have a 32 bit application that uses DAO to connect to an Access database. I need to upgrade the application to be true 64 bit (not WOW64). Microsoft does not offer a 64 bit version of DAO. The features I really liked about the Access database were that it was well-supported in Windows, it allowed multiple users to connect simultaneously (though the nature of our application is that it was never more than five or so at a time), and it was serverless. I have found two potential replacements: 1. Pros: serverless.
Cons: The documentation warns that having multiple users connect to a database over a network could result in corruption. Does anyone have any experience with this? Pros: Appears to be more robust than SQLite. Can work as an embedded database for single users. Cons: Requires a database server to be used for multiple users to connect to a file over a network. I am not considering SQL Server Compact or SQL Server Express.
Microsoft is too flightly with their database technologies for me to take these seriously. Are there any databases that I missed that I should be considering? Does anyone have any specific experiences with either SQLite or Firebird that would favor one or the other? Are my descriptions of SQLite and Firebird correct? What I mean by 'flightly' is they can't commit to a database technology. Joel said it better than I can in his Inc article: '(Microsoft's) technological cover fire has included no fewer than eight different 'official' ways to get data out of a database.
(For those of you keeping score at home, they were DbLib, ODBC, RDO, DAO, ADO, OLEDB, ADO.NET, and LINQ - and I'm sure I've missed some others.)' They've also recently replaced MSDE with SQL Server Express. If I could use 64 bit DAO, I would do it without a second thought. Microsoft is forcing me to switch database engines, so I don't really see any reason to stick with them. You can still connect to SQL Server with DAO. I wouldn't recommend it, but you can.
My current preferred connectivity is through ADO.NET with a Native SQL OLE DB provider. Changing the connection mechanism has not meant a lot of changes for the architecture of my database designs. SQL Server Express is simply MSDE 2005. It's basically the same thing with the 2005 engine instead of the 2000 engine.
All versions of SQL Server from CE to Enterprise have the same core functionality and you connect the same ways. You can easily move from SQL Server Developer Edition to Express to Enterprise as long as you are not dealing with clustering or any of the very specific features (attaching file databases in Express, too) or coming up against overall size limits. When you are dealing with SQL Server, you have a full server-based RDBMS, and, althought network connectivity is important, it should not compromise the ACID in the database engine, whereas with Access or anything file-based over the network, you're SOL.
I'm not pushing you to use SQL Server, but just pointing out some corrections to your assumptions and that it has been very stable for over the past 10 years, with very few fundamental differences since 7.0 which would affect your front ends. Lots of things you might want to take advantage of, but nothing at what I would call the core level of most applications. You haven't told us much about your application, but since it's multi-user, it sounds like it has a strong CRUD element.
SQL Server may not be apropriate for all kinds of scenarios where even flat files might be more appropropriate. Also, since we're talking about 64-bit and databases, I have to wonder what the importance of native 64-bit is - is this a heavy processing application, or requiring some very large database activity. Because SQL Server is a client-server RDBMS, you can easily have 32-bit clients connecting to a high performance 64-bit SQL Server and taking advantage of the SQL Server's power without worrying at all about client horsepower. In my daily experience, even an eight-way 64-bit SQL Server (Enterprise on Enterprise x64, 8-way Unisys, but not sure if it's 8xsingles, 2xquads or 4xduals) is only going to perform marginally better in small scenarios where a one-way or two-way 32-bit SQL Server desktop (Developer on XP Pro, Dual Core) is already adequate.
Your memory, disk array and database design are going to a have a bigger impact. Don: Yes, the SQLite corruption issue is a network / OS problem, not one with the database. We've had relatively few problems with Access, though they do happen occasionally. Have you (or anyone else) ever tried running SQLite over a Windows network with multiple users? If it's truly as robust as Access, that would be good enough.
Cade: I honestly tried to include enough information to avoid the 'You haven't told us enough' comment, without writing a novel. Sorry about that. I'll try to expand. Our software is an add-on for AutoCAD.
The 64-bit version of AutoCAD is native 64-bit. For our program to work with AutoCAD, we have to also be 64-bit.
The only thing driving the 64-bit conversion is compatibility with AutoCAD. There is nothing about our program that requires 64-bits. You are completely right that it is overkill, but it is unfortunately necessary.
The application is multi-user, but not many. In most cases, there is only one person connected. A large number of users working on a single database would be five. The software is used to design HVAC and electrical systems for buildings. Each building gets a separate database plus a number of associated AutoCAD drawings. The database and the drawings get moved around the file system a lot. Using Access, this isn't a problem.
I imagine this will get a little more complicated going with a client-server RDBMS (SQL Server or Firebird). And yes, I have been a little dramatic regarding Microsoft's databases.
That's just my frustration at the fact that the one solution I would love-upgrade Jet to 64-bit-they've decided not to do. Sqlite is at least, if not more robust than access. But, neither is particularly better over a network. I've supported several ms access-based solutions over the years.
One in particular corrupted once every few months. Always, the data was recoverable with a compact (or whatever) command from within the access environment. My 3 production sqlite applications have never corrupted. As far as i know ms access does not have true acid transactions (could be wrong, but i don't think so), so sqlite is probably a little more stable. If you're really, really concerned about network issues, then use mssql server or another client-server technology. Best regards, don.
SQLite is better at self-healing. I wrote an app for a university using Jet 3.5, and while Access supported transactions, commit/rollback etc., they only work while Access is running. If Access crashes, it will not self-heal. SQLite, with its journal file, will self-heal when the power comes back on. To me, that makes SQLite a more robust database. In the 5 years I was involved with the university, the vast majority of database problems were related to the network/windows, not Access. For the most part, Access was very solid, and we had 25 users on it.
I was hoping MS would rewrite 'Microsoft Jet Database Engine Programmer's Guide' for Jet 4, and it appears they were going to (based on Amazon.com pre-release information about the book), but decided against it in favor of MSDE. Jet 4 is great and has a place, especially for local databases. And if you need reports and scripting, you can use the full power of Access to manipulate your Jet database. But SQLite can be compiled right into your EXE, which in the end gives it a certain advantage. For what it's worth, everytime SQLite issues over a network are mentioned in the SQLite newsgroup, NFS file locking is always specifically mentioned. That's not a guarantee that Windows networking always does the correct file locking, but I haven't heard of any issues in the couple of years I've been following the newsgroup. I moved from Access to SQLite a few years back and have never regretted it.
I don't have multi-user, but I do often have two processes (and multiple threads) accessing the database. That used to mess Access up, but it's never happened with SQLite. (Note that I always had both the Access and SQLite databases on the local machine). Thanks to everyone for their replies. ADO exists for 64 bit, but there is no driver to connect to an Access database using it: I could split my code into two parts, but with the way the code is written, that would require almost as much work as my other options. I figure this is as good a chance as any to make a change to something that currently supporter. I agree, flightly was a bad choice of words to describe Microsoft's databases.
But I still won't use SQL Server. I've apparently been very lucky with Access over the last seven years. I'm still debating whether to choose if I prefer to be lucky (SQLite over a network) or good (Firebird). I would also second the suggestion for Firebird. The true free database aspect with no restrictions (free as in beer) are critical to us, along with the fact that I can develop one application against one database schema and deploy as either embedded vs.
A 'real' server that is still $0 cost to a customer. Its an ideal way, for example, to develop an application and give it away for trialware in single user mode by just providing Firebird embedded (a very small DLL BTW, under 2mb in total size). But if a customer wants to upgrade the software to multi-user, they just install FB server editions (again $0 cost) and point the application to that. All without having to suffer without stored procedures, triggers, views, etc. Since Firebird is the open source port of Interbase, it has a lot of great history & maturity, and its totally cross platform so you can offer your customers deployments on Windows, Linux, Sun Solaris, Mac OSX, etc.
The FB community are awesome for support (found mainly on Yahoo Groups) and its also a damn solid database for web applications (ie. PHP Interbase libraries are rock solid). As for admin tools, I use IBExpert and love it. Its rich, gives me the ability to debug stored procedures, etc. The best thing to do here is to create a list of your requirements and rate all options against them. We did this, and Firebird (still to this day) ranks highest amongst all options. The only other one that came close was PostgreSQL, but PGSQL didn't really make it easy to deploy a Windows trialware single user install of our software, so we dismissed it for that reason.
Good luck in your hunting!
Hi, We will just want to describe you of what we are trying to achieve. We are trying to compile a class file to a dll which is compatible on 64 bit Operating Systems and 64 bit Processors.Further we are wanting to call a function of this class file in an Excel VBA macro.The dll function returns a value and the macro reads that value and puts it to a specific cell of an Excel File. We are successfully able to achieve this on machines running 64 bit Operating Systems and 32 bit Office(Office 2003, Office 2007, Office 2010) and 32 bit Operating Systems. We are facing problems only with a combination of 64 bit Operating Systems and 64 bit Office. The steps we followed to compile the dll is as follows: I created a class library in visual studio 2008.The properties set in the Visual Studio Editor is as:-Application -Assembly Information-Make Assembly COM visible Check box Checked.
Compile - Register for COM interop Check box Checked(Which creates 'Sample.tlb' file) - Signing - Sign the Assembly.Check Box Checked(Which creates 'Sample.snk' file) - Set the Target CPU as 'Any CPU' and Target Framework as 'Microsoft framework 2.0' Advanced Compiler Setting As we build the solution, following files get created in the Release folder. Sample.Dll - Sample.tlb - Sample.snk - sample.Pdb - sample.xml Now I place the.dll file and.tlb file in system 32 and syswow64 folder. And then registered the dll as denoted below.- 1. By gacutil /i sample.dll 2. By RegAsm sample.dll After Registering DLL I Open the Excel then Create a Macro and add a reference of following files- -.tlb file - Microsoft ActiveX 6.0 object library(for 64 bit MS Office Excel) -'Microsoft Office 14.0 Access Database Engine Object' - Microsoft DAO Object Library 3.6 I create an object of the dll and call the dll function via the object created.
The problem we face is an Error code '429' at the point when in the Macro we call the dll function(Note: on machines with 64 bit Operating System and 64 bit Office). We researched a lot on this issue,but still could not resolve the same. Please, kindly help us address this issue with workaround. Thank You, Regards, Vaibhav Pandya. Thanks for the summary.
The references to Microsoft Active X 2.1 Object Library and Microsoft DAO 3.6 Object Library are 32bit dlls so will not work with Office 64bit even if you compile them into a 64bit dll or set as 'Any CPU'. The 64bit version of Microsoft Active X 2.1 Object Library is Microsoft Active X 6.0 Object Library.
There is no 64 bit equivalent for Microsoft DAO 3.6 Object Library. Depending on the functionality required you could try setting a reference to C: Program Files Common Files Microsoft Shared Office14 ACEDAO.dll This will show as 'Microsoft Office 14.0 Access Database Engine Object' but it may no give you the required features. Where is the data being obtained from? An Access database, SQL Server or a different source? When answering a question please:. Read the question carefully. Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome. Don't tell someone to read the manual. Chances are they have and don't get it.
Provide an answer or move on to the next question. Let's work to help developers, not make them feel stupid.
Did you try using the Microsoft Office 14.0 Access Database Engine object For access 2010, the standard DAO reference is the above and NOT dao 3.6. I not tested this with 64 bit edition. Addition that ADP does confuse this issue even more. The above reference should be available and that is the correct DAO reference to use/try in your case. The fact that you trying to use/run DAO code inside of ADP which tends to be ADO is certainly going to be a source of problems. However, I would give the above reference a try. Kallal (Access MVP) Edmonton, Alberta Canada.
As a follow up: JET direct has been depreciated, but the ACE engine is for all purposes the default. There would be no need to use DAO 2.0 or DAO 3.6. The NEW DAO default for 2010 is ACE. Again: The default is DAO for Access 2010. However, that default is certainly not some older version of DAO, be it 2, or 3.6. Virtually ALL OF my current DAO code works 100% fine in access 2010.
So, the only reason I can think that you need/want DAO 3.6 is for needing JET direct, and given that your talking about a ADP, this very well might be the case (but, I can't read your mind, so you have to clear up if in fact you are needing to use JET direct in your DAO code, or you just need to write/use DAO code). AGAIN: THE NEW DAO DEFAULT AND REFERENCE FOR ACCESS 2010 IS CALLED Microsoft Office 14.0 Access database engine Object Library AGAIN: If you set the above reference in a APP then you CAN USE dao reocrdsets and dao code will run and work just fine.
AGAIN: You can use the above refernece in an ADP and it works just fine. So, if you are looking to set a DAO reference in Access 2010, use the above. The above will work for a 32 bit ADP access 2010, and I suspect it should work just find for the 64 bit ADP access 2010 also. ACE is the new version of DAO, so just use it and it is the default engine.
Windows 7 Home Premium 64 Bit
Yes, good point – 100% agree. I really meant to say: You need to reference the ACE object library to use the new version of DAO.
So, just use it and ACE is the now the default data engine. My real point here is that when using accDB format files, you do not actually set a reference to DAO anymore, but set a reference to the ACE object library. In VBA code, you still dim things such as Dim db as DAO.database Dim rst as DAO.Recordset Albert D. Kallal (Access MVP) Edmonton, Alberta Canada Yes, that's what I do when I convert it to accdb or import an object from a mdb. I didn't need to remove DAO reference in every modules, reports and forms.
And it works in 64-bit Access as well. I also have ADO references, so I would prefered to remain the status quo. Correction: Access 2010 64-bit DOES support DAO. (Not sure about v.
3.6 but DAO is supported - I'm using DAO with the Reference GUID mentioned in my previous post.) Try adding the Reference by GUID. As for DAO being 32-bit code, I don't know one way or the other. But I do know that Access generally can only handle 32-bit numeric db fields. (64-bit VBA code works fine, but any 64-bit numeric data types that Access touches get implicitly converted into Text Strings. So you can interact with a 64-bit SQL database, only, you have to enclose your 64-bit numeric data in quotation marks, so as to trick Access into being compatible with this data type, and sending those data over to the SQL database that will treat the 64-bit quoted numeric type as a numeric type.) Matthew Slyman M.A. Yes, there is 64 bit edition of DAO. The issue of sql server is NOT related to ths issue.
When you use the 32 bit version of SQL server, or the 64 bit version of SQL server, it does not magically out of the blue and based on a whim all of a sudden change the data formats of the data word size being saved. The way the data format is stored does not change when you use a 32 bit version of SQL server, or the 64 bit version. It would be pretty amazing and silly to mess with the data formats; else any 32 bit or 64 bit client, or any 32bit or 64 bit versions of SQL server would rapidly turn the whole computer industry into a tower of Babylon.
The same goes for access when using the 64 bit edition, or the 32 bit edition, the format of DATA saved does not change. However, to be clear; there is a REAL 64 bit edition of the database engine when using Access 64.
Many programming languages when they made the jump from 16 to 32, didn't necessarily mess with the existing variable and word size (they added new ones as to allow existing code to work). So the change from 32 to 64 bits does not mean nor imply that the database file format is going to change in any way shape or matter.
In other words the database file formats, and the programming language and word size are two different matters. Now I will accept that one should make the assumption that the programming language as a general rule should be able to accept and manipulate the data and word size that comes out of the database system, but the reverse is not always the true either. In fact, it not true either way.
So for access 64 bit version, the long variable type is still only 32 bits. Int variable type is still only 16 bits.
However when you are using the 64 bit version of access, then the VBA language does offer NEW variable types. You have LongLong and this is a true 64 bit wide word size. However you do not have a change or equivalent of LongLong in the actual table designer, nor does the data format change nor has been a 64 bit word size added to the data file format. So just like the 32 bit or 64 bit eddition of SQL server, the data file formats and word sizes for data saved does not change in Access data files either. On the other hand the 64 bit edition a SQL server can address vast amounts of more memory directly in the computer, and the same would apply to access 64 bit version. Also keep in mind if you're using the 64 bit version of access, then you can only automate 'in process' other 64 bit programs.
So if you have the 32 bit version of outlook installed you WILL NOT be able to automate that version of outlook from access 64. And to save some posters coming back here to clarify this issue. You cannot mix and match 32 and 64 bit parts of office for the SAME version. So for office 2010 if you use 64 bit version of outlook, you'll have to use the 64 bit version of word. You CAN however install the 32 bit version of office from OTHER versions such as 2007. The reason for this is office is made of shared components, and if you install word on a machine, than any other part of office installed including Access will not even give you a choice as to what directory it's going to install into.
HDClone Professional v3.2.8 + Serial Creating identical 1:1 copies of hard disks and other media. For data rescue, backup, system restoration, mass installations and.
The shared parts are many ranging from spell checking, graphics filters, VBA editor and a whole slew of components are shared to all of office. Thus no mixing and matching of the same version of office is allowed in terms of word size (you cannot mix/match 32 and 64 for same version of office). And, this means that Access 32 cannot automatate Outlook 64 bit either. Now back to access 64 bit; You also have a new pointer variable type again that is 64 bits wide and this allows you to use the windows API (as once again with true 64 bit computing, you need a larger value than 32 bits to address memory and use the windows API).
Windows 7 64-bit Download
That new variable type is called longPtr (note that this variable is also available in the 32 bit version of access, and when you use the 32 bit version of access it is 32 bits long). However the same cannot be said for the new variable type called LongLong, it is ALWAYS 64 bits and in fact is not available in the 32 bit version of access. And there are about 6-7 new functions to convert the 64 bit variable size into strings or integers or whatever – just like we had in the past - (clng, cdbl etc.). So the 64 bit of version of access is a true 64 bit in process version of access, and just like SQL server 32 or 64, this fact is not reflected in the data file formats used nor the CPU processor data word size used with data that you save into those data files and formats. Kallal (Access MVP) Edmonton, Alberta Canada. I would agree if Access 2010 32-bit support DAO 3.6 32-bit. That's the way at the moment at my work place, I'm suggesting Access 2010 32-bit with Windows 7 32-bit instead of fully 64-bit in my company.
So there's no need to convert anything especially like the APIs. I guess it is hard to find out why MS exclude DAO in 64-bit Access by default.
The only problem I encounter is the VBA date format. Was running Access 2000 with Win 7 32-bit. It is showing a US date format instead of UK. That's normal in Access, but this works in Win XP with the Regional Settings(control panel) if it was set to UK. Win xp works fine but not in Win 7.
I really hate to convert anything, wish MS make it more simple where you can just run your old 32-bit mdb without any conversion. @Albert, You haven't taught me anything new in your essay, except to clarify a few things I'd already found out in practice about installation restrictions on different versions - a useful clarification for me. As for 64-bit data types. I was writing about that on my blog eight months ago. Most of what you have written is accurate (although simultaneously irrelevant to the OP, excessively verbose and insufficiently detailed on a technical level regarding the subjects you are now discussing), although a few of your suggestions just leave me scratching my head.
Have you tried the SQL Server BigInt data type? 64-bit numeric. Have you tried interfacing it via ODBC linked table from MS Access? Check out the data type according to MS Access table design view. No, it's not. It's a 64-bit numeric type, that MS Access 64-bit doesn't understand. Have you tried creating a 3GB MS Access 64-bit.accdb file?
Won't happen, at least not on the 2010 version. As for the rest, check out the signature on my MSDN posts, and you'll see that for me, most of that extra detail is totally unnecessary. If your post was shorter, I might vote it 'helpful', but with posts of this length, you really have to dig to find what you're looking for. Just a helpful suggestion to shorten your posts a little? I think your more valuable contributions would get a lot more exposure. Matthew Slyman M.A.
Until converted for human display, Date format fields/ variables are manipulated internally in Access using a standardised numeric representation (at least, internally standardised within MS Access/ VBA, I believe - with some possible conversion at the seams if you're interfacing with another RDBMS such as SQL Server). There's no US or UK date format, until you start looking at the values (at which point, there is an implicit type conversion to Text/String, to allow you to read the Date value more easily). If you're having trouble with date formats, I suggest:.
If you're interfacing with another RDBMS such as SQL Server, check the date formats used by SQL Server and your ODBC drivers are what your client workstations expect. In any case, you can explicitly use the Format function to ensure that dates are displayed in the format you desire. Other than that, you might find this information helpful (about VBA, Windows API and locale settings): Matthew Slyman M.A. Have you tried the SQL Server BigInt data type? 64-bit numeric. Have you tried interfacing it via ODBC linked table from MS Access? Check out the data type according to MS Access table design view.
No, it's not. It's a 64-bit numeric type, that MS Access 64-bit doesn't understand. Have you tried creating a 3GB MS Access 64-bit.accdb file? Won't happen, at least not on the 2010 version. Matthew Slyman M.A. (Camb.) The above is really very much my whole point. For what reason would you assume that the file size is going to change because we moved to 64 bits for the data engine?
My whole simple point is that just because you change the bits size of the data engine, that is not necessarily going to affect the file and data type size limits that you're allowed to work with. (it could but it is NOT necessary so and it is a poor assumption - these are mutually exclusive issues – ie: limits will.necessary. be increased). If you look at SQL server 32 bit, or 64 bit edition, the max data size file allowed is 542 terabytes. (I suspect this has something to do with the windows file limits, and not the database engine itself, but my point still remains intact). And what new data types did we get with 64 bit sql server?
Some more SQL stuff: Number of columns per insert statement in 32 bits = 4096 Number of columns per insert statement in 64 bits = 4096 columns per primary key in 32bit = 16 columns per primary key in 64bit = 16 The list of NON changes for 32 vs 64 bit sql server is very long. A lot of these limits in particular thus did not change when moving from 32 to 64 for SQL server.
So, if this is the case for SQL server, then why point out that somehow Access would be different in this regards? You seem to be suggesting in some way that because we gone to a 64 bit edition of Access, then somehow the file size will necessarily increase (it did not for SQL server). You're also suggesting that for some reason because we are now on Access 64 bits, all of a sudden the ODBC driver will return something different for bigInts (as number) and not a string as it did before. Again such behaviors never changed with SQL server when it went from 32 to 64, so why then expect it to change with Access? Maybe if you quoted some good examples of what limits and how the drivers changed and WHAT they return when we went from 32 to 64 bit SQL server I might be able to better grasp your point as to why you suggest something different should occur when access went to 64 bits as opposed to SQL server? There's really nothing material or logically I can see as to why access would necessarily change these limits any more so then SQL server did. If you're concluding that some of these limits are arbitrary limits and set the way they are, then I fully accept that.
I'd also say the same for SQL server. A nice list for SQL server is here, and again going to 64 bits did not change many limits: Thus based on recent computing history there's no reason to make such assumptions for Access any much different then what occurred for SQL server. Kallal (Access MVP) Edmonton, Alberta Canada. Matthew Slyman wrote: I am developing.accdb's on Access 2010 64-bit, and have no trouble finding the Microsoft DAO 3.6 Object Library. It appears to be installed on my machine my default.
Perhaps it's there because of some 32-bit software I have installed on my particular machine? Who knows but it works for me! Jet 4.0, DAO 3.6 and MDAC/ADO have been installed as part of the OS since Windows 2000.
Tony Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - Tony's Microsoft Access Blog - For a convenient utility to keep your users FEs and other files updated see. The default installation for Office 2010 is the 32bit version. I have installed the 64bit version personally to reflect what my employer has done, but likely would have installed 64bit anyway. 64bit is definately here to stay and knowing how to deal with situations in that environment was important to me.
Its a catch 22 really because I want to be using the 'lastest' thing, but going to Access 64bit, has some growing pains, especially if you will be in a mixed environment or depended on ActiveX COM Controls (ie: TreeView). To handle that (the mixed mode) I have created Virtual Machine's that have the environments I needed, but definately wanted my 'base' installation to be 64bit. Brent Spaulding Access MVP.
Right you installed windows 2008, but this is an MS Access forum. Did you also install Access? Actually, it much sounds like you NOT really using Access but only the database engine. So this would suggest you use JET or the later edition of that data engine called ACE. Your problem might be related to running x64 bit version of your web site and applications. If this is the case, then you have to use the x64 bit version of ACE or you MUST continue to use the x32 bit version of the web server.
So you have to mention what version of IIS you are running (x32 or x64). If you going to use DAO then you have to use + launch the x32 bit version of IIS for server 2008. The details of this can be found here: And alternative would be to replace your DAO references/connection string to use ACE which does have a x64 bit option - but I think it best you decide if you would rather launch + use the x32 bit version of IIS as compared to making changes in your code to use ACE in place of DAO.
Note that ACE is compatable with DAO, so only the connection string need be changed - rest of code should work. So in place of CreateObject('DAO.DBEngine.36') you use: CreateObject('DAO.DBEngine.120') You will as noted have to download the ACE engine to do the above, or consider using the 32 bit version of IIS.
Best regards, Albert D. Kallal (Access MVP) Edmonton, Alberta Canada. I had the same problem, having upgraded from Access 2013 to Access 2016, when opening a file that previously worked fine in Access 2013. At first, it wouldn't compile, and on checking the References, it was totally missing Microsoft DAO 3.6 Object Library. It didn't have the.MISSING. next to it - it simply wasn't there at all. I scrolled down the list to find it, and having checked the box, it told me there was a missing DLL.
On checking the Location, I too found I was missing the DAO folder from the C: Program Files Common Files Microsoft Shared directory. I found it under the C: Program Files (x86) Common Files microsoft shared directory, so copied it into the one above.
In the References list in Access 2016, I selected it and it accepted it, then compiled OK. Hope this helps. Sorry if the explanation is a little long-winded - we're not all tech gurus.:-). I had the same problem, having upgraded from Access 2013 to Access 2016, when opening a file that previously worked fine in Access 2013. At first, it wouldn't compile, and on checking the References, it was totally missing Microsoft DAO 3.6 Object Library. It didn't have the.MISSING.
next to it - it simply wasn't there at all. I scrolled down the list to find it, and having checked the box, it told me there was a missing DLL. On checking the Location, I too found I was missing the DAO folder from the C: Program Files Common Files Microsoft Shared directory.
I found it under the C: Program Files (x86) Common Files microsoft shared directory, so copied it into the one above. In the References list in Access 2016, I selected it and it accepted it, then compiled OK. Hope this helps. Sorry if the explanation is a little long-winded - we're not all tech gurus.:-). I had the same problem, having upgraded from Access 2013 to Access 2016, when opening a file that previously worked fine in Access 2013.
At first, it wouldn't compile, and on checking the References, it was totally missing Microsoft DAO 3.6 Object Library. It didn't have the.MISSING. next to it - it simply wasn't there at all. I scrolled down the list to find it, and having checked the box, it told me there was a missing DLL. On checking the Location, I too found I was missing the DAO folder from the C: Program Files Common Files Microsoft Shared directory. I found it under the C: Program Files (x86) Common Files microsoft shared directory, so copied it into the one above. In the References list in Access 2016, I selected it and it accepted it, then compiled OK.
Hope this helps. Sorry if the explanation is a little long-winded - we're not all tech gurus.:-). You should not need a reference to DAO.
All of your code should work and compile fine if you simply ensure that you have this ref: Microsoft office 16.0 access database engine object library It not clear why you having to include the DAO reference, but I would recommend that you try removing that reference and try compiling again. I have not tested, but perhaps you have code opening a mdb as opposed to a accDB file? (but in most cases this should not matter). You could post a offending line of code that is not compiling when you remove the dao reference, but as a general rule the reference to DAO is not required anymore. Regards, Albert D.
Kallal (Access MVP) Edmonton, Alberta Canada.
I have an application that makes use of various versions of an older COM dll. Some version of the dll use DAO 3.5 to access a Microsoft Access database and some use DAO 3.6 do to the same.
So, my install needs to make sure that DAO 3.5 and 3.6 get installed on the target machine so I can be sure this older COM dll will function, regardless of which version they choose to use. That said, I used to use InstallShield to create installation programs. Installshield has merge modules for just about everything, including DAO 3.5 and 3.6. I am trying to create a setup project in VS 2008 that will do the same. The problem is I cannot find out how to get DAO 3.5 and 3.6 to be included in my setup project. Any ideas on how to do this? Thank you so much!
Thanks for the reply. This article talks about how to include a merge module in a setup project. While this is useful, it isn't any help unless you have the merge module to include. Installsheild comes with a pretty complete library of merge modules to install lots of different Microsoft (and other) technologies. For example, to include DAO 3.5 and DAO 3.6, all you need to do is select those components from a list of re-distributable modules. All of the details (including the exceptions for different operating systems) are encapsulated within the merge modules.
What I seem to be finding out is that unless you are using installsheild, you have to build your own merge modules which means figuring out all the details. This isn't fun when it comes to installing the JET engine because of all the changes to MDAC made over the years. It used to be you could just install MDAC and you'd get the Jet engine and all the ODBC drivers.
Now it is split into two, and I don't know what the JET engine is packaged with. Can you confirm that Microsoft does not have merge modules that can be included in a visual studio setup project for its component technologies such as DAO?
Thanks again! Hi AndyCan you confirm that Microsoft does not have merge modules that can be included in a visual studio setup project for its component technologies such as DAO? Yes, Microsoft doesn’t offer these components’ merge module which InstallShield has. DAO 3.5 and Jet 3.5 are available on this page. You can also copy the one from InstallShield. Sincerely, Kira Qian in Forum If you have any feedback on our support, please contact Please remember to mark the replies as answers if they help and unmark them if they provide no help. Welcome to the.