My company has developed an application with Visual Basic 6.
The application uses an Access database via an ODBC datasource.
The Access database is a file with the ".mdb" extension.
We have not noticed any slow data access when running the application in the following environment :
OS : Windows 7 32 bits.
Installed version of MS Access : Access 2007.
Access driver used by the OBDC datasource : Microsoft Access Driver (*.mdb) version 6.01.7601.17632.
But we have noticed slow data access when running the application in the following environment :
OS : Windows 7 64 bits.
Installed version of MS Access : Access 2010 or 2003.
Access driver used by the ODBC datasource : Microsoft Access Driver (*.mdb) version 6.01.7601.17632.
I have googled for a while to find a solution.
Other developpers have experienced the same problem according to articles found on the Internet.
For information the tracing feature is not enabled in my ODBC 32 bits administrator.
The following page mentions the tracing feature :
http://answers.microsoft.com/en-us/office/forum/office_2010-access/my-solution-to-access-being-slow-with-odbc/a5a6522f-a70f-421e-af1b-48327075e010
I have also tried without success to disable the LLMNR protocol as mentionned in the following page :
http://accessexperts.net/blog/2011/11/02/windows-7-64bit-slow-with-access-2007-solved/
Any help will be greatly appreciated
There are number things to check, the first and foremost thing you want to do is create in your application what we call a persistent connection. A persistent connection simply means that somewhere in your startup code, you open up a table from the back end to a record set, and keep it open for the duration of any other operations you do in that application.
The reason why a persistent connection often makes a huge difference is that the newer operating systems tend to do have a tremendous amount of additional security and overhead when a connection to the databases created. And it turns out that generally opening and closing tables in access databases requires that these connections are also opened and closed. If you force the persistent connection to remain open at all times, then this very slow and large overhead process that interferes with general performance of general updates in your code will now not be incurred.
Give the above a try, since this setup very often cure is this performance issue and problem.
Related
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
I'm trying to develop a simple web application to run on my company's internal network. I've recently taught mysef the fundamentals of Vaadin and Microsoft Access. I've gotten Vaadin to access a simple MySQL database without any problems. I've also created the real database in Access. My question is how do I get the two to work together? Is there a driver I can use to access the .accdb database itself, or is there a format I can convert to that is compatible with Vaadin but can also still be administered with Access?
Using vaadin with a database is "simply" making the right choice for the JDBC drivers.
For MS Access you can either go via the ODBC Bridge, or purchase a professional JDBC driver.
When you go the ODBC bridge way, you then have to make sure that the server java vm matches the odbc version. Either both 32 Bit or both 64 Bit.
Look here: How to connect to Access .mdb database from 64-bit Java?
In the meantime MS has provided 64 Bit ODBC drivers for MS Access too. But the platform needs to be Microsoft Windows.
Please be aware, that MS Access is a bit tricky when using in multiuser mode. If it's a real project, then you should consider migrating it to a real database.
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.
Well, this is a bit awkward. I currently have a set of reports on a 32-bit sql server 2005 instance that references an access database on a network location. I'm currently trying to migrate these over to my new reporting services instance (sql server 2008 64-bit), and i've ran into an issue.
Well, i did a google search on the error and got a bunch of stuff saying to compile to use x86 and use 32-bit, etc., but none of it even touch on if i was getting this in rpeorting services.
My question is, is there a way to "fix" this, or some sort of work-around? Perhaps there's another provide i can use to get to the access database?
Any ideas would be much appreciated.
Ran into the exact same problem today, as you alluded to there is no 64-bit Microsoft.Jet.OLEDB.4.0 provider available. This impacts reports that attempt to use Excel and Access datasources on a 64-bit Reporting Services instance. Here is the KB article confirming that no 64-bit Jet driver is available:
http://support.microsoft.com/kb/957570
The solution I found is from this forum post on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9e999fb4-5a39-41c4-8fd7-46193a223673/
It involves creating an SSIS package that reads the Excel or Access data source, running the SSIS package in 32-bit mode, and using the SSIS package as the report datasource. Not ideal, but it works.
I'm afraid this is the nasty workaround to which we're limited.
I ran across this, which worked in a specific case:
http://danielcai.blogspot.com/2011/02/solution-run-jet-database-engine-on-64.html
From that post:
Microsoft has released a 64-bit compatible Jet database engine last year. The following is the procedure that you may use to fix this issue:
Download Microsoft Access Database Engine 2010 Redistributable (of
course you'll need to choose the right bit for your server), and
install it on your server
Change your connection string in your code or configuration file from
Provider=Microsoft.Jet.OLEDB.4.0;
to
Provider=Microsoft.ACE.OLEDB.12.0;
My question about the reconfiguration delay when switching between Access 2003 and 2007 the comment was made:
Btw, you can't avoid the reconfiguration between Access 2007 and earlier versions. Access 2007 uses some of the same registry keys as earlier versions and they have to be rewritten when opening Access 2007.
If this is so then is it actually safe to be running/developing databases in both versions at the same time? Do the registry changes affect the operation of Access once it has started up. For example recompiling/saving changes to objects?
It works most of the time but it's not perfectly safe, which is why Microsft refuses to support multiple installations of Microsoft Office on the same pc. The recommended solution is to install a virtual machine and install the second Microsoft Office version on the virtual machine. Then you can switch from one version of Access to the other without them interfering with one another (and no switching time wait!)
Microsoft offers a free download of Virtual PC 2007 in both 32 bit and 64 bit versions:
http://www.microsoft.com/downloads/details.aspx?FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6&DisplayLang=en
Here's the service pack:
http://www.microsoft.com/downloads/details.aspx?FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5&DisplayLang=en
It is perfectly safe, I have done it very often (both running and developing). As soon as you open a database in Access 2007, some extra properties will be added to the database. However, this is done in such a way that you can still open the database safely in Access 2003 at a later time.
We also have databases installed in a multi-version environment were different people use the same backend, with the front end opened in Access 2003 or 2007.
It seems to me that the instance of Access you open will inherit the registry settings at the time it is open. So, if you open A2K7, you'll get the registry settings that it writes in its "configuring Office" procedures. If while A2K7 is still open, you open A2K3, it will reconfigure the registry settings and inherit those for its session. This will have no effect on the already-running instance of A2K7.
The only possible exception would be if there are some registry keys that the "configuring..." process changes that Access doesn't read upon opening, but later in the session. I have strong doubts that MS would ever design things that way. Professional Access developers been dealing with this kind of thing since MS introduced the MS Installer (first seen by most people with Office 2000), and the A2K7 issues are only slightly worse than with previous versions (though on Vista, it's more complex because of the way Vista handles registry changes). The fact that MS gets the vapors over contemplating multiple versions of Access on a single PC does not mean that it's actually dangerous -- it shows only that they don't want to devote resources to supporting that scenario.