views:

104

answers:

2

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.

+1  A: 

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).

Tony Toews
Yeah I'm using sp2 12.0.6535 and the customer is as well... I looked at that hotfix and it doesn't seem to help.
Patrick
+1  A: 

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.

pghcpa
Er, why would there be any T-SQL involved, since SQL Server is not being used here?
David-W-Fenton
In regard to maintaining a persistent connection (which really just means making sure the LDB file is created once and kept open), Tony Toews has thoughts here: http://www.granite.ab.ca/access/performanceldblocking.htm . It's actually unnecessary to open a recordset -- all you need to do is initialize a database variable pointing to the back-end database, which will cause the LDB file to be created. You'll need to clean that up in your app's shutdown routine (though you'd need to do that with a recordset, too).
David-W-Fenton
Patrick wrote "tsSQL" (presumably a SELECT) statement in his rs.OPEN command. He didn't give us the SQL assigned to that variable. Perhaps it includes a join on fields that are no longer indexed after he upsized from 2003 to 2007 or maybe subqueries or something that used to work but now is slower due to underlying db changes.
pghcpa
Why don't you edit your answer to refer to "tsSQL" instead of "tSQL" and indicate that you're using the original question's variable name. I can't be the only one who's going to get tripped up on that.
David-W-Fenton
thanks for the input. I ended up rebuilding the table structure and during that I verified the indexes were proper. I also verified the sql, its all basic sql no sub queries or joins. Since the application is all object oriented, and It appeared to only be an issue when there were multiple users i knew it had nothing to do with the sql itself perse. i looked into the ldb issue and found that if i created a persistent connection at application start and closed it at the end everything worked much better.
Patrick