I have a Microsoft Access database application, written in Visual Basic for Applications. I find that when Real Time Protection is enabled, and my code tries to make repeated edits to the database in quick succession, the first one will succeed, but often one of the subsequent edits will fail with the message "Cannot update. Database or object is read-only". The problem goes away when I disable RTP. It seems like McAfee is accessing the file somehow which is preventing Microsoft Access from having full read/write access to the file. Here's the code if that helps:
Dim rs As Recordset, i As Integer
Dim KeyName As String, KeyVal As String
KeyName = "SomeKey"
KeyVal = "SomeVal"
For i = 1 To 10
Set rs = CurrentDb.OpenRecordset("OH Table", dbOpenDynaset)
rs.FindFirst "[Key] = 'SomeKey'"
If rs.NoMatch Then
rs("Key") = KeyName
rs.Edit ' THIS LINE FAILS WITH ERROR "CANNOT UPDATE. DATABASE OR OBJECT IS READ-ONLY"
rs("Field1") = KeyVal
Any ideas as to what's going. What is McAfee doing with the database file that is interfering with my program?
The fast rewriting to the file might be read as virus like activity. There is a feature in Real time scanning settings called Boost my protection. The setting is Scan for viruses by identifying threat patterns try turning that off and see if that helps.
If not I will ping a virus lab tech to comment.
Thanks for responding to my issue. I tried your suggestion, but the errors persisted. I tried disabling Real Time Defense, and that didn't help either. However, when I switched the option from All Files to Programs and Documents only, that seemed to help, which is a bit strange, since the .mdb files were in a subfolder of My Documents. Do you have an explanation for this?
I would appreciate if a lab tech would be involved with this as well. My program is actually a commercial desktop database application, with numerous customers, and I would like some definitive information.
Is there some way to tell McAfee to exclude certain files/folders from protection?
Programs and documents I assume does not include mdb file type. I have emailed a tech to have a look here.Message was edited by: Peacekeeper on 19/10/13 6:42:30 AM
exctly - a .mdb file is neither a program or a document.
I expect VBA is just getting caught out by the on-access scanner. The first access to the file will trigger a scan, which has not finished by the 2nd access. Why not put a "doevents" in your loop to slow things down and let the OS keep going, or put a trap in for the error and just retry after pause?
I'm thinking a different RecordSetOptionEnum might help as well, but it's a long time since I did any VBA
Peter : I just downloaded the latest trial version of Internet Security. The customer who alerted me to these problems was using the same version. I just received an email today from a second customer reporting the same error. Pretty strange! My program has been on the market for 15 years, with about 400 customers, and never a single problem with this. Now, in one week, I've got 2 of the exact same issue.
SafeBoot : If all we were dealing with was that simple little loop I posted above, I would agree that just checking for the error and waiting to get access to the file would be the way to go. But I've got 40,000 lines of code in this program, and you're basically asking me to do a total rewrite of the program, so I'm sure you can appreciate that I'm not to keen on that suggestion.
I hope you realize that Microsoft Access is a full fledged, multi-user, fully concurrent database access system. It might not be as robust and scalable as SQL Server or Oracle, etc, but it is very sophisticated and good at what it does. It has a very well defined record locking system to facilitate multi-user access, and your real time scanner has run a torpedo right through that whole thing. Basically what I would have to do is implement my own record locking, concurrent access system in my code to account for the fact that your scanner is just going in there and locking the file whenever it wants to, without telling anyone!
Unless something better comes up, I'm going to recommend my customers switch real time protection to Programs and Documents Only. I can imagine some of them won't like that though. I really think you need to modify the way you deal with MS Access database files.
There are three paths that I think you could take. 1) Leave MS Access database files alone. 2) Or, when you do your scan, open the file in READ mode with full sharing. (I take it you're putting some kind of read or write lock on the file when you open it, based on the error message I'm seeing. Or do you temporarily mark it as Read-Only?) That way it has zero impact on MS Access. 3) But if you really do need to put a lock on the file, then you need to do it in concert with the file locking system that MS Access already uses to govern multi-user access. Basically it uses a .LDB locking file to indicate who has what portion of the file locked. So what your scanner needs to do is check that .ldb file to see if anybody is currently using the file. If so, you wait. If its not in use, you put the proper entry in the .ldb file to indicate to MS Access that you're now going to lock the file so it knows that it needs to wait. Then you do your scan, and when you're done you take the entry out of the .ldb file. This is all a bit theoretical, as I'm sure you would have to work with MS to get some of the details on how to work with that file.
Hoping there's some easy way out of this for everybody,
If you want the home version to exempt something from a scan you are going to have to submit it and I made up a how-to here: https://community.mcafee.com/thread/2016
Otherwise contact Technical Support as I think this is too technical to answer here, for me at least.
We now have another user reporting this so it would appear that there's an issue with a recent update and Access.
Technical Support may be the best route for this, linked under Useful Links at the top of this page.
The more cases they get the better.Message was edited by: Ex_Brit on 19/10/13 9:26:43 EDT AM