Gracefully Handling Multiple Users Accessing the Same File Simultaneously

Gracefully Handling Multiple Users Accessing the Same File Simultaneously

Anonymous
Not applicable
328 Views
2 Replies
Message 1 of 3

Gracefully Handling Multiple Users Accessing the Same File Simultaneously

Anonymous
Not applicable
I found out the hard way that when many users are trying
to do run an OpenTextFile statement on the same file at
the same time then some users will get the
"Permission Denied" error.

In order to solve the problem what I did was write a function
like the one below which tries to test if a file is currently
being open and being read or written to by another person.

I have put line numbers here just for ease in referring to
portions of the program.

10 Function IsReadyToOpen(strFileName As String) As Boolean

20 Dim blnIsReady As Boolean, fle As New FileSystemObject
30 Dim tst As TextStream

40 On Error GoTo errHand

50 blnIsReady = True

60 Set tst = fle.OpenTextFile(strFileName, ForReading, False)
70 tst.Close
80 Set tst = Nothing
90 Set fle = Nothing

'''no permission denial everything went as expected

100 IsReadyToOpen = blnIsReady

110 Exit Function

120 errHand:

'''permission is being denied

130 blnIsReady = False
140 IsReadyToOpen = blnIsReady

150 Set fle = Nothing

160 End Function

I am concerned that I might inadvertently corrupt
file or lose data due to this function and want it to be as
programming tight as possible.

You will notice this as the heart of the routine that if the
function issues the OpenTextfile and it fails then it will set the
return value to false in line 130-140 then just set fle to nothing

I am not so comfortable with not closing a file before setting
fle to nothing. But the problem I have is what will happen if I
try to issue a tst.close in a line say 145. I am not too sure how
that will work... first an error in opening has made the execution
jump to this point and if the said tst.close in 145 causes yet
another execution error already from within the error handle then
will that leave me in a crash on top of data loss or file corruption?

In other words how do I execute this thing as gracefully as possible
making sure that files are properly closed and fle set to nothing?

I would be open to any ideas in case anybody knows of any technique
that will allow me to know if a file is already open without actually
issuing an OpenTextFile method ... such a technique would be safer
I think.

Thanks you so much for all the kind help you can give.

Matt
0 Likes
329 Views
2 Replies
Replies (2)
Message 2 of 3

Anonymous
Not applicable
I simply do not see why you need this while you can apply the same On
Error...to handle file open exception directly. That is you just do

On Error Resume Next
'Open File
Open FileName For...
If Err.Number<>0 Then
'File open exception handling...
End If

instead of

If IsReadyToOpen(fileName) Then

'Open file here.
'However, it is not 100% guaranteed there is not another attempt
'to open the same file between IsReadyToOpen() and actual Open... being
executed.
'Because the stream/file open/close in the IsReadyToOpen() only tells
you the file may
'not be opened in the short period of open/close inside IsReadyToOpen().

End If

The problem is not user get "Permission Denied" error. It is inevitable
sometimes, if the file is opened by someone exclusively. You just need to
handle it correctly. It is for sure trying to open it twice and only handle
it in the first time is not the correct way.


"matt_1ca" wrote in message news:5836627@discussion.autodesk.com...
I found out the hard way that when many users are trying
to do run an OpenTextFile statement on the same file at
the same time then some users will get the
"Permission Denied" error.

In order to solve the problem what I did was write a function
like the one below which tries to test if a file is currently
being open and being read or written to by another person.

I have put line numbers here just for ease in referring to
portions of the program.

10 Function IsReadyToOpen(strFileName As String) As Boolean

20 Dim blnIsReady As Boolean, fle As New FileSystemObject
30 Dim tst As TextStream

40 On Error GoTo errHand

50 blnIsReady = True

60 Set tst = fle.OpenTextFile(strFileName, ForReading, False)
70 tst.Close
80 Set tst = Nothing
90 Set fle = Nothing

'''no permission denial everything went as expected

100 IsReadyToOpen = blnIsReady

110 Exit Function

120 errHand:

'''permission is being denied

130 blnIsReady = False
140 IsReadyToOpen = blnIsReady

150 Set fle = Nothing

160 End Function

I am concerned that I might inadvertently corrupt
file or lose data due to this function and want it to be as
programming tight as possible.

You will notice this as the heart of the routine that if the
function issues the OpenTextfile and it fails then it will set the
return value to false in line 130-140 then just set fle to nothing

I am not so comfortable with not closing a file before setting
fle to nothing. But the problem I have is what will happen if I
try to issue a tst.close in a line say 145. I am not too sure how
that will work... first an error in opening has made the execution
jump to this point and if the said tst.close in 145 causes yet
another execution error already from within the error handle then
will that leave me in a crash on top of data loss or file corruption?

In other words how do I execute this thing as gracefully as possible
making sure that files are properly closed and fle set to nothing?

I would be open to any ideas in case anybody knows of any technique
that will allow me to know if a file is already open without actually
issuing an OpenTextFile method ... such a technique would be safer
I think.

Thanks you so much for all the kind help you can give.

Matt
0 Likes
Message 3 of 3

Anonymous
Not applicable
Thanks for this valuable answer ... I will keep all your suggestions in mind and will try to revise my program accordingly.

Gratefully,
Matt
0 Likes