Dao 3.5 Windows 7 64 Bit
I have an application that uses the MS Access 2003 front end to connect to both a MS SQL and a Sybase database. This application uses VBA (Visual Basic 6) and this cannot be changed. We are in the midst of a conversion from Windows XP (where the application runs fine) to Windows 7.
On Windows 7, attempts to connect to the Sybase databsae fail. The application uses a pass through query and when the failure occurs, I receive the following message: An unexpected error occurred in CallSP. Error number: 48 Error description: Error in loading DLL Error source: Secure open security The particular line of code where this is throwing the error is: For Each qryDef In dbLocal.QueryDefs The items in this line of code are defined like this: Dim dbLocal As Database Dim qryDef As QueryDef Set dbLocal = CurrentDb When originally launching the application, there was a missing reference for Microsoft DAO 3.6 Object Library. I copied the dao360.dll file to C: Program Files (x86) Common Files Microsoft Shared DAO, registered it using regsvr32.exe, and set the reference (Tools - References) to this file.
Dec 16, 2013 Ideally you'd create a Windows Installer database (.MSI file0 using a DAO 3.5 Merge Module. Microsoft never released one, since DAO 3.5 was obsolete before Installer itself was mature though. You'd have to hunt for a 3rd-party-built Merge Module, for example the one at Windows Installer Merge Modules, about 2/3 of the. To add to my previous post, 32 bit DAO works fine in a 64 bit environment and for relatively simple database applications it is preferable as it is a lot less bloated.
At this point, I suspect the problem may have something to do with user rights on this machine, but I'm stuck on where to start. Users do have 'read and execute' rights on the dao360.dll file. We have a lot of legacy apps written in Access, so our systems use Access 2003, but Word, Excel, and Outlook 2010. We are moving to Windows 7 64-bit. If I was in your shoes, I would try the following:. Remove and re-install Access And I would run a registry cleaner like CCleaner to remove broken library reference from the registry before re-installing Access and applying all updates. The fact that the dao360.dll was missing or improperly registered shows that there is at least one installation issue on that machine.
Also, remove and re-install your ODBC drivers for the other databases. Try on the same machine from a different user Create a new user on the machine, then log under that user and check if you still get the issue. Try from a different machine Use the same database, make sure the DAO references are selected, and try code query again.
If it still doesn't work, then there is another issue somewhere, and it's not related necessarly to DAO. You mention using Sybase and SQL Server. Are the ODBC drivers functioning properly? Could there be some corruption there too on the machine?
What if you create a new database and try a single pass-through query using the same connection string?. 32 and 64 bits mixup Are you sure all dependent software and database drivers are installed for 32bit? If you are trying to access an ODBC data source that uses a 64bit driver from a 32bit app, it will fail. In Win7 x64 the ODBC console available from the Administrative Tools in the Control Panel is not 32bit! You need to create your DSN using C: Windows SysWOW64 odbcad32.exe instead. There is no need to attempt to re-register the dao library here and doing such is a silly wild goose chase and amounts to wasting company resources.
Installing Access 2003 on that computer should work just fine and installing 2003 on that computer will ALSO correctly install the DAO libraries (attempting to copy and re-register the DAO library has the potential to turn your computer into a complete mess here – don't do this and it not required). There are either some broken references or perhaps the ADO library was placed higher up in the references as compared to the DAO library. In fact check the references in the VBA editor. If ADO is not being used, then remove the reference.
Also if outlook is being used from this application then remove the outlook reference in this application. You REALLY need to use late binding for Outlook automation code. I have run Access 2003 on windows 7 x64 since the win 7 beta and I had zero problems here. This is nothing to do with x64 or win7, but only that of behaviors of a typical broken reference. The solution that I came up with was to use weak typing, and to reference all DAO objects through CurrentDb. The only references I have in my project are VBA and the Microsoft Access Object Library, which are required anyway.
Dataproducts ink. It is a bit radical, but it does give you something that can be deployed on any platform. The project of every newly created Access database includes a reference to a DAO library.
But DAO library references are no longer updated when databases are deployed on different machines. That feature was broken in Access 2007, when the DAO library was renamed. In your example, this would be: Dim qryDef As Object For Each qryDef In CurrentDb.QueryDefs.
SQL Server Native Client is a stand-alone data access application programming interface (API) that is used for both OLE DB and ODBC. SQL Server Native Client is included in SQL Server. SQL Server Native Client can be used to create new applications or enhance existing applications that must take advantage of new SQL Server features. (Microsoft/Windows Data Access Components are not updated for new features in SQL Server.) The SQL Server Native Client OLE DB provider was included in SQL Server Native Client in SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, and SQL Server 2012.
After SQL Server 2012, the SQL Server Native Client OLE DB provider will no longer be included in SQL Server Native Client. The MSI to install SQL Server Native Client is available on the SQL Server media and in SQL Server Feature Packs. After SQL Server 2012, the ODBC driver will be updated for the most recent server features, including Microsoft Windows Azure SQL Database, and released as the. With Microsoft/Windows Data Access Components (MDAC/WDAC), developers can connect to and use data from a wide variety of relational and non-relational data sources. You can connect to many different data sources using Open Database Connectivity (ODBC), ActiveX Data Objects (ADO), or OLE DB. You can do this through providers and drivers that are built and shipped by Microsoft or that are developed by various third parties.
With Microsoft/Windows Data Access Components (MDAC/WDAC), developers can connect to and use data from a wide variety of relational and non-relational data sources. You can connect to many different data sources using Open Database Connectivity (ODBC), ActiveX Data Objects (ADO), or OLE DB. You can do this through providers and drivers that are built and shipped by Microsoft or that are developed by various third parties. Current MDAC/WDAC Architecture. These components are supported in the current release.
Use these components when you develop new applications or upgrade existing applications. ODBC: The Microsoft Open Database Connectivity (ODBC) interface is a C programming-language interface that allows applications to access data from a variety of Database Management Systems (DBMS). Applications that use this API are limited to accessing relational data sources only. ODBC will continue to be supported and is available on the 64-bit Windows operating system.
OLE DB: OLE DB is a comprehensive set of COM interfaces for accessing a diverse range of data in a variety of data stores. OLE DB providers exist for accessing data in databases, file systems, message stores, directory services, workflow, and document stores. OLE DB core services (although not every OLE DB provider) is available on the 64-bit Windows operating system.
ADO: ActiveX Data Objects (ADO) provides a high-level programming model. Although a little less performance than coding to OLE DB or ODBC directly, ADO is straightforward to learn and use, and it can be used from script languages, such as Microsoft Visual Basic Scripting Edition (VBScript) or Microsoft JScript. ADOMD: ADO Multi-Dimensional (ADOMD) is to be used with multidimensional data providers such as Microsoft OLAP Provider, also known as Microsoft Analysis Services Provider. No major feature enhancements have been made to it since MDAC 2.0. ADOX: ADO Extensions for DDL and Security (ADOX) enable the creation and modification of definitions of a database, table, index, or stored procedure. You can use ADOX with any provider.
The Microsoft Jet OLE DB Provider provides full support for ADOX, while the Microsoft SQL Server OLE DB Provider provides limited support. No major enhancements are planned for ADOX in future MDAC/WDAC releases; however, it is available on the 64-bit Windows operating system.
Microsoft SQL Server Network Libraries: The SQL Server Network Libraries allow SQLOLEDB and SQLODBC to communicate with the SQL Server database. The following SQL Server Network Libraries have been deprecated in MDAC/WDAC releases: Banyan Vines, AppleTalk, Servernet, IPX/SPX, Giganet, and RPC. TCP/IP and Named Pipes will continue to be supported and are available on the 64-bit Windows operating system.
MSDASQL: The Microsoft OLE DB Provider for ODBC (MSDASQL) is a technology that allows applications that are built on OLEDB and ADO (which uses OLEDB internally) to access data sources through an ODBC driver. MSDASQL is an OLEDB provider that connects to ODBC, instead of a database. MSDASQL ships with the Windows operating system, and Windows Server 2008 and Vista SP1 were the first Windows releases to include a 64-bit version of the technology. Deprecated MDAC/WDAC Components.
These components are still supported in the current release of MDAC/WDAC, but they might be removed in future releases. Microsoft recommends, when you develop new applications, that you avoid using these components. Additionally, when you upgrade or modify existing applications, remove any dependency on these components. SQLOLEDB: The Microsoft OLE DB Provider for SQL Server (SQLOLEDB), which supports access to Microsoft SQL Server, has been deprecated. Its connectivity to future versions of SQL Server may not be supported. The ability to connect to versions earlier than SQL Server 7 will be removed from the operating system after Windows 7. New applications should use the SQL Server Native Client OLEDB provider, which supports new SQL Server features.
Existing applications should migrate to the SQL Server Native Client OLEDB provider as well for better performance, reliability and supportability (see for more information). SQLODBC: The Microsoft SQL Server ODBC Driver (SQLODBC), which supports access to Microsoft SQL Server, has been deprecated. Its connectivity to future versions of SQL Server may not be supported. The ability to connect to versions earlier than SQL Server 7 will be removed from the operating system after Windows 7. New applications should use the SQL Server Native Client ODBC driver (or the successor to the SQL Server Native Client ODBC driver, the Microsoft ODBC Driver for SQL Server on Windows), which supports new SQL Server features.
Existing applications should migrate to the SQL Server Native Client ODBC driver as well for better performance, reliability and supportability (see for more information). Microsoft Jet Database Engine 4.0: Starting with version 2.6, MDAC no longer contains Jet components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC/WDAC releases do not contain Microsoft Jet, the Microsoft Jet OLE DB Provider, the ODBC Desktop Database Drivers, or Jet Data Access Objects (DAO). The Microsoft Jet Database Engine 4.0 components entered a state of functional deprecation and sustained engineering, and have not received feature level enhancements since becoming a part of Microsoft Windows in Windows 2000. There is no 64-bit version of the Jet Database Engine, the Jet OLEDB Driver, the Jet ODBC Drivers, or Jet DAO available.
This is also documented in. On 64-bit versions of Windows, 32-bit Jet runs under the Windows WOW64 subsystem. For more information on WOW64, see. Native 64-bit applications cannot communicate with the 32-bit Jet drivers running in WOW64. Instead of Microsoft Jet, Microsoft recommends using or when developing new, non-Microsoft Access applications requiring a relational data store.
These new or converted Jet applications can continue to use Jet with the intention of using Microsoft Office 2003 and earlier files (.mdb and.xls) for non-primary data storage. However, for these applications, you should plan to migrate from Jet to the 2007 Office System Driver. You can, which allows you to read from and write to pre-existing files in either Office 2003 (.mdb and.xls) or the Office 2007 (.accdb,.xlsm,.xlsx and.xlsb) file formats. Note SQL Server applications can also access the 2007 Office System, and earlier, files from SQL Server heterogeneous data connectivity and Integrations Services capabilities as well, via the 2007 Office System Driver. Additionally, 64-bit SQL Server applications can access to 32-bit Jet and 2007 Office System files by using 32-bit SQL Server Integration Services (SSIS) on 64-bit Windows.
MSDADS: With the Microsoft OLE DB Provider for Data Shaping (MSDADS), you can create hierarchical relationships between keys, fields, or rowsets in an application. No major feature enhancements have been made since MDAC 2.1. This Provider has been deprecated. Microsoft recommends that you use XML, instead of MSDADS.
Oracle ODBC and Oracle OLE DB: The Microsoft Oracle ODBC Driver (Oracle ODBC) and Microsoft OLE DB Provider for Oracle (Oracle OLE DB) provide access to Oracle database servers. They are built by using Oracle Call Interface (OCI) version 7 and provide full support for Oracle 7. Also, it uses Oracle 7 emulation to provide limited support for Oracle 8 databases. Oracle no longer supports applications that use OCI version 7 calls.
These technologies are deprecated. If you are using Oracle data sources, you should migrate to Oracle-supplied driver and provider. RDS: Remote Data Services (RDS) is a proprietary Microsoft mechanism for accessing remote ADO Recordset objects across the Internet or an Intranet.
Windows 7 64-bit Torrent
RDS is deprecated; no major feature enhancements have been made to RDS since MDAC 2.1. Microsoft has released the.NET Framework, which has extensive SOAP capabilities and replaces RDS components. All RDS server components will be removed from the operating system after Windows 7. JRO: Jet Replication Objects (JRO) is deprecated.
JRO is used within ADO with Jet (.mdb) databases to create and compress Jet Databases (.mdb’s) and perform Jet Replication Management. MDAC 2.7 will be its last release. JRO will not be available on the 64-bit Windows operating system. JRO is not supported in the Microsoft Access 2007 file format (.accdb). 16-bit ODBC Support: If you are using 16-bit applications, you should migrate to a 32-bit application. 16-bit functionality is deprecated and is being removed from 64-bit operating systems; see for more information. OLEDB Simple Provider (MSDAOSP): OLEDB Simple Provider offers a framework for quickly building OLE DB providers over simple data.
MSDAOSP is deprecated. ODBC Cursor Library: ODBC Cursor Library (ODBCCR32.dll) provides limited client-side data cursors.
ODBC Cursor Library has been deprecated; your application can use server side cursor implementations as a replacement. OLE DB Out-of-Process Interface Remoting: OLEDB Interface remoting (msdaps.dll) was an attempt to allow OLE DB providers to run out of process. OLEDB Out-of-Process Interface remoting is deprecated. AppleTalk and Banyan Vines SQL Network Libraries: The Banyan Vines, AppleTalk, Servernet, IPX/SPX, Giganet, and RPC SQL network libraries are deprecated. If you are using any of these technologies, you should modify your applications to use one of the other network libraries, such as TCP/IP and Named Pipe.
MDAC/WDAC Releases. Here is a list of the supportability scenarios of past, present, and future MDAC/WDAC releases, starting with the earliest.
MDAC 1.5, MDAC 2.0, and MDAC 2.1: These versions of MDAC were independent releases that were released through the Microsoft Windows NT Option Pack, the Microsoft Windows Platform SDK, or the MDAC Web site. These versions of MDAC no longer are supported. MDAC 2.5: This version of MDAC was included with the Windows 2000 operating system. Service packs of MDAC 2.5 were included with corresponding Windows 2000 service packs.
However, Microsoft currently supports only MDAC 2.5 SP3 on Windows 2000 SP4, and serviceability is subject to the lifecycle of the operating system. MDAC 2.6: MDAC 2.6 RTM, SP1, and SP2 were included with Microsoft SQL Server 2000 RTM, SP1, and SP2, respectively. Additionally, these MDAC service packs were released to the MDAC Web site in accordance with the Microsoft SQL Server 2000 service-pack release schedule. You can install this version of MDAC and its service packs on Windows 2000, Windows Millennium Edition, Windows NT, Windows 95, and Windows 98 platforms.
This version of MDAC no longer is supported. MDAC 2.7: This version of MDAC was included with the Microsoft Windows XP RTM and SP1 operating systems. You can install this version of MDAC and its service packs on Windows 2000, Windows Millennium, Windows NT, and Windows 98 platforms. You can install this version on the Windows XP platform only through the operating system or its services packs. This version of MDAC no longer is supported. MDAC 2.8: This version of MDAC was included with Windows Server 2003 and Windows XP SP2 and later.
You also can install this version of MDAC and its service packs on Windows 2000. The 32-bit version of MDAC 2.8 also was released to the MDAC Web site at the same time that Windows Server 2003 was released to the customer. The 64-bit version of MDAC 2.8 was released with the 64-bit version of Windows Server 2003 and Windows XP. Windows Data Access Components (WDAC): MDAC changed its name to WDAC - 'Windows Data Access Components' since Windows Vista and Windows Server 2008. WDAC is included as part of the operating system and is not available separately for redistribution.
Serviceability for WDAC is subject to the life cycle of the operating system. 32-bit and 64-bit versions of WDAC are released with the 32-bit and 64-bit versions of the Windows operating systems, respectively. For more information about MDAC releases, see. Obsolete technologies are technologies that have not been enhanced or updated in several product releases and that will be excluded from future product releases.
Do not use these technologies when you write new applications. When you modify existing applications that are written by using these technologies, consider migrating those applications to ADO.NET. The following components are considered obsolete:. DB-Library: This is a SQL Server–specific programming model that includes C APIs. There have been no feature enhancements to the DB-Library since SQL Server 6.5. Its final release was with SQL Server 2000, and it will not be ported to the 64-bit Windows operating system.
Embedded SQL (E-SQL): This is a SQL Server–specific programming model that enables Transact-SQL statements to be embedded in Visual C code. No feature enhancements have been made to the E-SQL since SQL Server 6.5. Its final release was with SQL Server 2000, and it will not be ported to the 64-bit Windows operating system. Data Access Objects (DAO): DAO provides access to JET (Access) databases.
This API can be used from Microsoft Visual Basic, Microsoft Visual C, and scripting languages. It was included with Microsoft Office 2000 and Office XP.
DAO 3.6 is the final version of this technology. It will not be available on the 64-bit Windows operating system. Remote Data Objects (RDO): RDO was designed specifically to access remote ODBC relational data sources, and made it easier to use ODBC without complex application code.
Dao 3.5 Windows 7
It was included with Microsoft Visual Basic versions 4, 5, and 6. RDO version 2.0 was the final version of this technology.