Printable View
Hi,
I'm trying to get my application to read to and write from an Access database. I am running Windows 7 x64.
If I disable UAC, I don't the error. If I have UAC enabled, then the error occurs. Here is a screen shot of the error:
http://www.lynxcode.com/bugs/2010-01-30_0032.png
Anyone have any input?
Welcome to VBForums :wave:
Where is your database file stored?
I suspect it is within Program Files (or some other protected location), which will cause this kind of problem. For more information, see the article Where should I store the files that my program uses/creates? (but ignore the code, as it is for an older version of VB).
If that isn't the issue, make sure that you have set apt permissions for the database file and the folder it is in, as explained in the article How do I use an Access database from multiple computers (in a network)? from our Database Development FAQs/Tutorials (at the top of the Database Development forum)
Hey! Thanks for the input!
I have placed the database in multiple different locations (root, appdata, mydocuments, etc) no matter where it is, if UAC is enabled, I get that error.
I will check out the other link. Thank you again for the input!
Yup, checked the permissions. I have already given full control to admins, users, system, etc.
Still get the error. Again, if I turn off UAC, no error. If UAC is on, error occurs. I think it's a problem with UAC on Windows 7 ??
Based on many previous threads with similar kinds of issues, I would be amazed if UAC itself has a problem - I strongly suspect that there is something you are doing (or have done) which is causing the issue.
Unfortunately it isn't always easy to work out why that is. My two suggestions above are the most common, but aren't always the cause.
Just to check, have you set permissions for the database file and the folder it is in? (due to the way Access databases work, you need both).
The only other thing I can think of at the moment (which seems unlikely) is whether or not your application is running as 32-bit, because there is currently no 64-bit driver for Access files. It is something you can change in the compile options for your project (rather than "Any CPU", select "x86").
Thanks again for the input.
Permissions for both the file and folder(s) are set accordingly. Back in December of 2007, I discovered that if I'm running 64-bit, the OLEDB drivers won't function, so I have set the application to compile explicitly for x86.
I've been developing and updating this application since 2007, and have never had this issue (even with Vista UAC). I upgraded to Windows 7 (clean install) recently, and discovered if UAC is enabled, I cannot write to the database. I CAN read from the database, but cannot write. If UAC is disabled, no problems.
Perhaps I have something set up wrong, but I am certain it is none of the issues you have mentioned.
I may be new to this forum, but I am not new to computers or programming. I came here because all other information resources regarding this topic have failed to be useful. I've googled every possible combination of words I can think of, and still no help.
My current development rig and details:
Windows 7 64-bit. Built in debug in both VS2008 and VS2010 beta 2. Built in release in both VS2008 and VS2010 beta2. Using Access 2007. Using an old mdb file that has been working perfectly across a company network stored on a local server for over three years. Working from home, the mdb file is stored locally on my C drive. I am running as administrator (with full permissions), mdb file stored locally, UAC enabled, compiling in x86.
I have a laptop with VS2008 and Win7 64-bit, if UAC is enabled, same problem.
That's why I came to these forums. Because it is a problem I have not been able to solve on my own.
I am sorry if I presented a problem that no one else has encountered...
Unfortunately I'm out of ideas at the moment.. but should have a new computer within a week (with the same setup as yours), so might be able to work it out then. In the mean time all I can suggest is creating a test app with the bare minimum needed to read and write to the database, and see if it has the same issues (if so, try another database too).
Hopefully somebody else will have some ideas.
There's nothing to be sorry about, there always needs to be a first time to solve an issue!Quote:
Originally Posted by gigabeard