with proper error handling, that shouldn't be an issue. crash, as in you mean that the code fails, right? in your handler, you really should have this:
Code:
Call objPropSets.Close(FilePath)
I see that you're doing that in the coding anyway through each file op. right? if that is closing it the code needs to be changed. but if that is indeed an equivalent op to visual basic's CLOSE statement during I/O ops, putting it in the error handler is all you need to do.
but if your access app crashes all-together, no there's nothing you can do about it during that instance.
by the way, i don't think opening the file in read-only (if you even had that option) is part of a solution. read-only is not part of the problem. at least not in traditional i/o ops in visual basic. it assigns integer values as indexes to files when they are opened in i/o. if you leave the file stream open without closing it I believe the file number still keeps association to that actual file until you close the app and destroy the memory usage completely.
but traditional i/o statements like open (for access), opentextfile, etc... have modal arguments that you can specify the type of stream. stream - read-only, input, output, append, read, write, binary.