Is it necessary to have Access installed when using odbc connector to access Access files?
I have an Access file db, which is used by my application. I want to install this application on another pc, so I also need to move the file.
Will I be able to access Access file if I copy the file and have my application installed together with odbc connector? Or do I also need Access (for some dlls?) to do that?
The short answer is no.
The long answer is . . . longer.
If your app using the MDB file for storage only then all you need on the clients machine is MSDAO - Microsoft Data Access Objects.
There are different versions of DAO libs for different version of Access, you should be able to lookup which version you require for your version of access easily enough.
Later versions of MS Windows often come with DAO libs already installed.
If your app is firing up MSAccess Forms or Reports in the database then you do need to have MS Access installed
While the answer about using DAO is correct, you also have the choice of using ADO and optionally ADOX, supplied by Microsoft as part of the MDAC package. It has a smaller memory footprint than DAO and is usually faster. The same restrictions apply in that you can read and write data, create, modify, and drop tables, but not use Access forms or reports.
ADO is still supported as a COM based interface for Access and many other databases. ADOX (for table modification) is depreciated, but still works.
ADOX and DAO are both "Jet only" interfaces, meaning that they work with Microsoft Access's "Jet DB Engine", but will not work if you later change the underlying database.
The OBDC connector you mention should work well, using ADO.NET (recommended for new code) and still has the same "data only" restrictions. This interface should still work if you later want to change the database to SQL server or MySQL.
Related
I am working on Universal Windows Application. I want to read ms access database file, But it seems like System.Data.Oledb namespace is not available in UWP.
I don't want to use any Web Service which requires internet connectivity.
Is there any solution for reading MS Access file in UWP?
Thanks in advance.
There are no way to do it. Only one avaliable DB format is SQLite.
You can use some converter tool
By the way, soon would be available Entity Framework for SQLite databases (it is in preview now)
One of our employees created a Microsoft Access Database and has built a Joomla! module around it. It is currently running on a WAMP server, with an ODBC connection to the accdb file.
How can I create an ODBC connection on Ubuntu for the Access database?
At this point, I'm open to having the DB live locally on my Ubuntu server, or on an SMB share somewhere.
Moving it from Access to MySql has already been proposed. It may come down to that, but I'm really being pressured to find another option.
Does anyone know if this is possible and how to accomplish it?
I'm sorry if this question has already been asked; I truly did look for it already, but couldn't find anything specific to connecting Access via ODBC on Linux.
I'm not entirely sure I understand the use case here, but here are a few thoughts:
Access databases are file-based databases and therefore server-less.
This means that the database file itself can reside on a local Windows machine, a windows network share or a SMB share on a linux box.
However, the application that queries the database must have access to the necessary drivers to manipulate the database.
On Windows, this is not an issue: All Windows version come pre-installed with the Jet drivers for the old .mdb format.
For the new .accdb format, you must have one of MSOffice 2007/2010/2013, Access 2007/2010/2013, Access Runtime 2007/2010/2013 or the standalone ACE driver installed to be able to use the new database format.
On Linux, the mdbtools package provides some degree of compatibility with the .mdb file format, allowing such a database to be queried and modified by a Linux application directly.
Another Open Source library (java) for manipulating (.mdb and .accdb) databases is jackcess.
ODBC drivers for Linux exist, but as far as I know, they are commercial and can be fairly expensive, see the easysoft Access ODBC Driver.
See also this SO question: Connecting to access database from linux
Basically, if you are looking for an easy solution that would be Open Source, going to MySQL or using a local SQLite database will be a lot more workable on Linux.
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 Call_SP.
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.
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. 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
Problem ocured when x86 and x64 version of OS/Access are instaled.
You need to create directory (I'm sure it does not exsit and You need administrative rights to do this):
C:\Program Files\Common Files\microsoft shared\DAO
Copy dao360.dll from C:\Program Files (x86)\Common Files\microsoft shared\DAO
to the directory created in step (1)
Now add reference in your VBA application.
From what I understand, I can no longer use ODBC to connect to Visual Foxpro 9 tables in Microsoft Access 2007. I see that I need to connect using OLE DB. I downloaded the Visual Foxpro provider, but I haven't found the instructions to complete my link or import from within Access. Does anyone have an answer?
Found It. Microsoft dropped the ODBC driver but this one worked for me. XP SP2
http://www.topol.eu/articles/download%20odbc
Seems like there is a way to use odbc
The ODBC drivers for FoxPro tables are not included with later versions of Access.
The simple solution is to download the ODBC drivers for FoxPro.
http://msdn.microsoft.com/en-us/vfoxpro/bb190233.aspx
Once you do the above, then you can use the standard import options from access to pull the data in, and in fact you can actually link to the table and edit the data from access without having to import.
In fact you can use the link provided by Jeff, but just have to install the above driver first.
Also the above driver supports the so called free tables. That’s when a database was considered a directory, and each dBase file place inside the directory would appear as a table that exists in a given database (thus a database was essentially a folder with files for each table).
When the windows select data source dialogue comes up, you’ll have to click on a machine data source, and they are you’ll see a choice of two drivers that you just installed. Just pick the visual Foxpro database driver.
Simply install the above ODBC driver, then use external data tab on the ribbon, and choose ODBC, the wizard will start, and you can link or import that visual FoxPro Data.
As a side note, then above link is a little bit confusing, you want to scroll down a little bit and choose the MSI file…not the first download choice.
Microsoft has chosen to not release a 64-bit version of Jet, their database driver for Access. Does anyone know of a good alternative?
Here are the specific features that Jet supports that I need:
Multiple users can connect to database over a network.
Users can use Windows Explorer to copy the database while it is open without risking corruption. Access currently does this with enough reliability for what my customers need.
Works well in C++ without requiring .Net.
Alternatives I've considered that I do not think could work (though my understanding could be incorrect):
SQLite: If multiple users connect to the database over a network, it will become corrupted.
Firebird: Copying a database that is in use can corrupt the original database.
SQL Server: Files in use are locked and cannot be copied.
VistaDB: This appears to be .Net specific.
Compile in 32-bit and use WOW64: There is another dependency that requires us to compile in 64-bit, even though we don't use any 64-bit functionality.
Luckily, things have changed in the past two years:
Since Office 2010 is available in a 64-bit version, Microsoft had to create a 64-bit version of their Jet Engine. According to the Microsoft Customer Service blog, the Microsoft Access Database Engine 2010 Redistributable contains a 64-bit driver, which is able to access recent versions of the Microsoft Access database format.
Users can copy the database while it is open without risking corruption.
You can't do that with any database file with multiple users and/or processes modifying it.
What you're looking for is SQL Server Express with the portable .mdf files. To get around the copying limitation you need to make sure that the software in question doesn't keep connections open (i.e. create a disconnected data access layer).
Try to have a look at http://www.vistadb.net/
#Orion: Agreed, OP would be advised to go with SQL 2005 Express (if possible). The deal breaker is being able to copy the DB while in use/attached which is out of the question with SQL without using some kind of backup tool that can copy 'in use' files.
Another way would be to automate a backup and restore to roaming machine but this is getting a long way away from being able to just grab a copy of the file.
Another alternative you can look at is SQL Server Compact Edition (CE). I believe this has 64bit binaries.
I also agree with Orion and Kev about the copying the database.
What I am going to do is to create a separate 32-bit executable that connects to Jet that my 64-bit application can communicate with through COM.
This satisfies my general requirement of "work like Jet", because it is Jet. My customers don't get the benefit of 64-bit, but the other requirements are more important.