I have an Access 2007 application (previously in Access 2003) that is running into some performance issues when the linked database tables are on a network drive. In 2003 the application worked perfectly fine. Now in 2007 the speed of data retrieval using sql and a recordset is degraded pretty poorly. The exact area that i am encountering the issue is on:
DIM rs AS NEW ADODB.RECORDSET
rs.Open tsSql, CurrentProject.AccessConnection, iKeyset, iLock
The iKeyset is set to 0 and iLock is set to 3
the rs.Open command is taking from 4 - 5 seconds which is an issue due to the fact that on some of my forms this can happen multiple times on load.
any thoughts?
EDIT: not to mention that I believe that opening and saving forms in design view appears to be slower than normal under these circumstances.
Depending on the SQL statement involved (i.e., your variable 'tsSQL' above) , your recordset should open instantly whether ADO or DAO.
Ideas that come to my mind: is your connection persistent? This seems to cause more of a delay in 2007 than in 2003. Maybe it's dropping and re-establishing the connection each time. With forms this happens when your recordsource is blank and set in code, so one is advised to always have a recordsource such as "tblBlankTable" (a small one-record table just to keep the connection alive all the time in a form that is always open). The 4 to 5 second delay is about what you get when this is not in place. Try making sure you have a form connected to your DB all the time when running your rs.open and see if that works. Possibly you might need a form with an ADO connection open in your case. Lots written out there on Access forums about this.
Is it faster when you are the only user versus when others have the DB with a lock file open? That is the tell-tale sign.
Another idea is whether you indexed everything correctly when you upgraded. Did the underlying DB stay the same or get upsized from MDB to ACCDB? You didn't indicate what is in the tSQL, so maybe you are joining on non-indexed fields or something that is causing that particular tSQL to run slowly and just need to add a primary key.
If your 'tsSQL' involves queries, I've read that when upgrading it is important to recompile all your queries -- go into design mode with each one, then run them, then save them again.
You could try connecting to the DB with your own connection string -- there is one format for MDB/Jet and another for ACCDB/Ace. There are providers for both that one usually uses from Excel to MDB or ACCDB, but maybe could work within Access, at least to debug your problem.
There is a hotfix Description of the Access 2007 hotfix package (Access.msp): August 26, 2008 that mention performance issues however this is very likely included in Access 2007 SP2. Click the Office button >> Access options (lower right hand corner) >> Resources tab and see what the section titled about Microsoft Office Access 2007 shows. Mine states 12.0.6535.5005).
Related
I have an MS Access frontend which is using a SQL database as backend. To connect, I use a ODBC connection and have created the needed entries in "ODBC Data Sources (32 Bit)"
When I will give the database to others, they will need to create this data source. I have a batch file for this so they can just run it.
If they do not run it, they will get a fault like "ODBC connection to XY failed". How could I change this error or at least write a second Message Box afterwards where I can tell them "run the Batch file XY to connect"?
When I will give the database to others, they will need to create this data source.
that is your first bad mistake and assumption. You MOST certainly do NOT want to deploy your applcation that way.
The way you deploy?
You take your accDB file, and link the tables to sql server. And you link using what is called DSN-less connections. Such connections do NOT require ANY data source to be setup on each work station.
So, ok, now you linked the tables to sql server (the production one - you probably were developing local on your developer PC and using a local copy of sql server express edition.
So, so now you link the tables to THEIR server, and then you now compile the accDB down to compiled executable version of Access - a accDE.
You are now free to deploy this "application" to any and all workstations for that company - and they do not have to re-link tables, do not have to setup a data source, and in fact they don't have to do anything, but simply run/launch the applcation.
How to make and get a dns-less connection?
Well, the MOST simple way is to ALWAYS, but ALWAYS ALWAYS create the linked tables using a FILE dsn. In fact, when you launch the ODBC connection manager from Access, the default is to use a FILE dsn. Never, and do not use "system" or "user" dsn.
If you link the tables using that FILE dsn, then Access converts them to DNS-less connections. At that point, you can even delete the DSN you created - access 100% ignores the DSN, and you don't need it anymore.
Next up:
If you been using nc 17 or nc 11-18 drivers? then yes, each workstation MUST have that same driver installed. Or, you can use the older "legacy" sql driver. But be careful - the legacy driver does not support datetime2 columns data types.
So, MAKE double, triple, quadrible sure that you not using data types and columns that require the newer drivers.
Right now, for some of the larger sites, we STILL use the older "legacy" driver, since that driver is installed at the OS level, and has been installed on every copy of windows going back to windows xp - in fact windows 98SE edition started shipping that driver. So you can 100% assume that the legacy sql driver is and will be installed on each workstation.
And by using + adopting dns-less connections, then no setup of the connection on each workstation is required. As long as those work stations are on the same network to sql server when YOU linked the tables, then they are good to go.
Now, on some sites, we actually can't even be on site, and we can't even pre-link to their sql server. So, what we do is on applcation startup, we check the current link for a linked table, and if it does not match a little external text file we ALSO included when setting up the work station, then we use VBA code to re-link the tables on startup. But once again, re-link of tables in VBA is easy, and again does NOT require ANY KIND of "dsn" or odbc setup on each work station.
And in fact, another way we used to do this is have a table in the front end, and it had one record, and that record had the connection string. So, right before deployment, we just edit that one record table in the front end to have the correct connection to their sql server. And once again, on startup , we check a linked table, and see if the connection strings match, if they don't, then we run the VBA re-link code, and once again, zero configuration and zero need exists to setup anything at all on each work station.
So, as a general rule, every dog, frog, insect that deployed access applications? We setup some re-link code and check that link on startup. In fact most developers have done this even without sql server - and even when using a access back end, then re-link code is included to resolve this issue.
but, be it linking to a access back end, or sql server back end? Some time of link check and system is assumed to have been cooked up by you, and this code will run on startup to check if the linked tables are pointing to the correct location.
But, be the back end oracle, sql server or whatever? You can create what is called dsn-less linked tables. As noted, you can use VBA to do this, or in fact you can use the linked table manager ---- as LONG AS you use a FILE dsn when you linked, then access coverts that to dns-less for you, and you be good to go.
so, in effect, you don't have to test/check/know for a odbc fail, since you checked the correct connection string on startup.
However, there is a way to trap, and check for a odbc failure, and this involves using a DIFFERENT way to connect, since we all know that if you have a odbc fail, you are duck soup (you have to exit Access, and there is NO KNOWN way around this issue - (well, except for testing if you can connect, and you do NOT use a linked table - since as noted once a odbc connect error triggers, it is game over.
The way you do this "alternate" test is like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
So, above does not hit or use a linked table. And a HUGE bonus of above? Once you execute that above valid logon, then any and all linked tables will work - AND WILL WORK without even having included the user/password in that connection string for the linked table. This is in have a huge bonus in terms of security, since now you don't have to include the user/password in the linked tables which of course exposes the user/password in plane text for all users that could look and see and find the sql user/password used.
In fact, what this means is that you can link your tables, but NOT include the user/password when you link the tables!!! - this is a HUGE security hole plugged and fixed when you do this.
So, once a valid logon has occurred (such as above), then any and all linked tables will now work, and work without even having included the user/passwords in those linked table connection strings.
As noted, the other big bonus is that you can use the above code to test for a valid connection, and avoid that dreaded "odbc" error, since as noted, if a odbc connection error is EVER triggered at any point in time, you MUST exit the applcation - no other way out.
However, it should be noted, that if you ever are going to use a wi-fi connection, or say cloud based sql server say running on Azure?
In that case, often with wi-fi, or a cloud based edition of sql server, then of course such connections over the internet are prone to minor and frequent dis-connects.
ODBC was developed long before the internet, and long before people would do things like connect access to some cloud based sql server running, and using a connection over the internet. But, if this turns out to be your use case, and deployment case?
Then you have to bite the bullet and ASSUME and ENSURE that you now adopt the nc 11-18 drivers. (I would go with nc17). These new drivers are now "internet" aware, and they are able to gracefully handle minor dis-conects, and in fact automatic re-cover and re-connect.
So, if you are ever going to use wi-fi, or connect to cloud based server? Then yes, you have to link the tables using say nc17 newer drivers, and you ALSO MUST THEN ensure that the same driver version you linked tables with is to be installed on each work station. You still don't have to setup any dsn connection and all that jazz - but you do have to ensure that the driver you used is ALSO installed on those work stations.
As noted, for larger deployments, we thus use the standard "legacy" sql driver, as it would be too painful to go to all work stations and install this driver.
However, we had one location, and for months they were experience in odbc connection failure. We had them replace a router, and even a network card on a server - but the problem still remained.
We suspect that some workstations had aggressive power management turned on, newer windows 10-11 will often put the network card to sleep, and thus when using access, we were seeing odbc errors. So, for that company, we had them install nc17, and linked access to sql server using that driver, and the problem went away (because those newer drivers now have built in re-connect ability - this is a relative new feature of ODBC, and one that legacy systems and drivers don't have.
I have several clients that I make databases for, all are pretty similar... They all have a screen with current data displayed. This screen/pc combo also sends some emails, uploads data, etc... usually without problems... however, one client keeps getting an 2004 (Not enough memory) and 3035 (system resources exceeded). I have tracked the memory usage on the device and it hasn't gone about 50%. I ran a memory test and no errors were found.
Today, I notice the error and was able to try a few things. With Access open, I could not open or design view any forms. Some queries I could get to open to SQL, but not design view. Crosstab queries would not open in design or SQL. Neither would open and show any data.
These errors are usually logged, and I will get several 2004s in a row, then it will switch to several 3035s, then eventually it will just quit altogether. Closing Access and reopening will always fix it (for a while).
I have decompiled and recompiled. I have tried accdb and accde versions. This is Access 2007. What should I try next?
Can't add as comment, but one thing to try would be to check the service pack level for Access, the latest for Office 2007 is SP3.
Also, if the issue is with multiple forms, then it could indicate database corruption rather than issues with individual forms. Have you tried to import all objects into a brand new container and run it from that?
I have a MS Access 2010 DB with bunch of forms,queries ,macros, Reports etc
The data for my report comes from ODBC links to SQL Server 2000 Tables via linked table property.
Now, whenever i goto design mode of a report,Everything moves painfully slow (I have to wait atleast half a minute for every mouse click,or to select a text box , or any operation performed on the report)
The report itself takes about a minute to run.Which i dont mind.
All I am looking for, is a quicker way to make changes to the design of reports.
This is an old question, but I had a similar issue with form design running extremely slowly recently. For me, only one form seemed to be affected (all others ran fine in design mode). The record source for the form was a complex query built on a hierarchy of subqueries. I dumped the query results into a table and used the table as the record source for the form instead of the query. This appears to have resolved the issue. Hope this helps someone else.
I found the main cause to be the Access conversion program that converted 2003 format to 2010. If you create a new .accdb and then import all of your object, it should work OK. I definitely fixed my issues
What worked for me is based on the answer provided by Albert Kallal at http://www.utteraccess.com/forum/lofiversion/index.php/t1959800.html.
For me, in my split database, if I open any table that is linked to the backend then opening any frontend form or subform was very quick. If I do not have open and keep open a linked table, then it takes about 20 seconds to switch from Form View to Design View and another 20 seconds to open a subform, etc. When I have a linked table open (it does not matter which table, just any table linked to the backend), then it takes about 1 second to do any of those functions. Huge difference!
That is not normal. Something is wrong. Could be your Office/Access installation, your OS installation, something taking up too much of the system CPU, or your system just not having resources, like memory, to properly run Access. Or that your DB is corrupted and/or bloated.
Two tests you can try.
First, do a compact/repair on the DB and see if that fixes it.
Second, is to start your computer in Safe Mode and see if Access still runs slow. This will test for much of the above issues.
What worked for me was to change the subdatasheet name from 'auto' to 'none' on all local tables. Do this in the property sheet in table design mode. There are routines posted elsewhere that will find all your local tables and change this value.
A table was linked to an Excel file. I found that when the Excel file was open, it took forever to change to design view on ANY form. Closing the Excel file eliminated my problem!
My case is access work fine in every function except opening or designing report. But access can work fine when network disconnect. I found it's cause by printer share by other computer and the computer which was removed. I remove the printer from control panel and access can work smoothly.
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.
I am using MS Access 10 in a multi-user environment. The DB is split with tables in the back end (stored on a network drive), and everything else in the front-end (stored on about five different computers).
Some of the front-end computers are using Access 07, but the DBs were created in the 07 format. I have checked that the database is NOT using the 2010 encryption, and all the other 10 settings that are not compatible with 07. In fact, the 07 computers will run the DB just fine when alone... the problem is when more than one person logs into the DB.
Often there is a "Too Many Active Users" error when trying to sign in. Other times, users are able to log-in and open forms, but whenever changes are made we get "locked" errors. (This happens on all computers, not just the ones running 07).
All the DB copies have record-level locking, but it behaves as if it is locking the entire table. I have checked, and none open the DB in "exclusive" mode. (When you go to the navigation pane, and open the table, the table itself will not allow new entries).
I have tried creating the forms based on queries and also with filters instead. I get the same locking problems either way (Does anyone know if queries or filters lock data differently?).
This is forcing the DB to be used by one user at a time, when multiple people need access. Is there anything I am overlooking? All have permissions set to the network drive, I removed the "compact on close", I tried converting to an ACCDE file (the ACCDE file will not open in 07, only 10, but we get the same locking errors).
Can anyone think of what I might be missing here?