Wow, I haven't seen or heard about such an issue. Be interested in knowing more about it if true.
What have you tried to do to isolate the problem
Is your "single user" testing being done with the MDB on a file server or local
What happens with multiple connections (from multiple client program instances) on the same machine with a local MDB
What exactly are you using for a file server Vista seems to have changed a lot of things from the way it does NTLM authentication by default to... who knows what I've read that some NAS devices require an authentication level change on Vista clients through security policy settings for example. Perhaps there are performance tweaks required as well
I suppose what I'm getting at is trying to figure out whether this is a Jet problem or a problem with the way Jet uses network shares on Vista.
What kind of application compatability is in effect for your program Does it have an Application Manifest that specifies the required execution level
More fishing...
Is there a performance problem when only doing simple SELECT queries or is it fine until you update What CursorType and other parameters are you using
I'm thinking it's locking related, of course. I assume you're holding connected Recordsets for extended periods of time. Does your client multiplex activity over a single connection or leave multiple Connections and Recordsets open (yes, two different issues). I'm thinking ADO here but DAO or ADO.Net will have a lot in common anyway.
If ADO have you considered turning on row-level locking Then again you might still be locking up lots of rows, depends on what you're doing.
Sorry, I'm probably barking up the wrong tree.
Since it is not a known issue, your best recourse is to use your Microsoft Partner Support benefits and report this in an incident (as opposed to advisory). If it is confirmed to be a bug, then it would not be decremented against available incidents.
If you are not currently a Microsoft Partner, please see the following link:
http://www.microsoft.com/presspass/press/2005/apr05/04-12ISVAdvisoryPR.mspx