Access Denied Problem

[MattC]

Hi,

Sorry about the long-windedness of this.

I have an intermittent problem with R/W-ing files. The program's problem part, in essence, has to access a file (in fact, it does this in several areas, but one main one), read records and write records. The user can add a new record, delete an unwanted one and edit one. The records are pulled into the system one at a time rather than holding all in the memory. In order to simplify the system, the three actions - 'New', 'Edit' and 'Del' - use two routines to finalise the action - 'Del_rec' and 'Save_rec'. 'New' uses 'Save_rec'; 'Del' uses 'Del_rec'; and 'Edit' used 'Del_rec' then 'Save_rec'. Both 'Del_rec' and 'Save_rec' copy the relevant records from the original to a temp file, either adding or removing a record. The temp file is then renamed as the old - now deleted - file.

Therefore, when editing a record this (should) happen after previously retrieving the record to edit.
1. Copy all the original file's records across to the temp file except for the selected record (the one being edited).
2. Delete the original file.
3. Rename the temp file to the original's name.
4. Delete temp file.
5. Copy all the original file's records across to the temp file adding the new/edited records in at the appropriate place.
6. Delete the original file.
7. Rename the temp file to the original's name.
8. Delete temp file.

This seems to work 80-90% of the time. However, every now and then I get an 'Access Denied' error (somewhere after 4 I think as the second temp file doesn't get created) - I think accessing the original file again. This causes a problem in that it has deleted the record, but crashed before it has saved the new/edited version causing it to be lost. I can't see that I've left channels open or anything like that. And it wouldn't work most of the time if that were the case anyway. (Note, that's 80-90% of the times that I access the files after running the program - not after I have edited half a dozed records - which would indicate the channels not being closed.)

Is there any other known issue that might cause this (and I'm not suggesting there's a problem with BB4W, just my programming)?

Matt

[DDRM]

Hi Matt,

That seems rather a complex series of operations. Why not:

1) Open the original
2) Open the temp file
3) read in records up to the one to be edited, and write them to the temp file
4) Read in, edit, and write the edited record to the temp file
5) Read in the remaining records, and write them to the temp file
6) Close both files (at this stage, everything should be safe!)
7) Delete the original file
8) Rename the temp file

That way if there is a problem with the write for some reason, the original file will still exist. I'm assuming you are using this method because the records are of variable length - otherwise you could use a random access approach simply to replace the edited record!

So why is there an intermittent problem? Without seeing/playing with the code I'm not sure (and I might not be sure then!). I suspect it might be to do with caching of the files before they are written to disk. Are you sure you close all files before deleting/renaming them? If not, the buffer may not be flushed, and data may be lost. This could easily be intermittent.

Best wishes,

D

[MattC]

Hi D,

There are two main reasons. One is that there needs to be a delete routine for the delete option, and there needs to be a save(add) routine for the new option. There would then have to be a third one - far more complicated - for the edit. Two, the fact that it would have to be more complicated is due to the fact that the edited record would not necessarily go back in the same place. Now, for a master programmer this is probably stuff that is written in ten minutes. Me, however, as a long-term novice... There is almost certainly a way of writing a single routine that does the whole job - and I may get round to changing it in the future - but for now, if there's a way to stop the error occurring as I have it, that would be good.

Matt

[Edja]

Matt,
Your program flow includes the following steps:

3. Rename the temp file to the original's name.
4. Delete temp file

I wonder how you perform step 4 since after you've renamed the temp file in step 3 the temp file doesn't exist anymore under its previous name and thus cannot be deleted. The same goes for steps 7 and 8.

Or do you copy the temp file to a new one with the original's name.
Maybe a look at your code may clarify if I'm on the right track ?

Edja

[MattC]

Hi,

A little round-the-houses but like this:

Code: Select all

     DEF FN_FILE_RENAME(filename$)
      IF FN_fileexists(filename$) THEN OSCLI "DEL """ + filename$ + """"
      IF FN_fileexists(filename$ + ".tmp") THEN
        OSCLI "REN """ + filename$ + ".tmp"" """ + filename$ + """"
      ELSE
        = FALSE
      ENDIF
      = TRUE


      DEF FN_fileexists(file$)
      IF FN_checkpath(file$) = 1 THEN = TRUE ELSE = FALSE


      DEF FN_checkpath(path$)
      LOCAL dir%, sh%
      DIM dir% LOCAL 317
      IF RIGHT$(path$)="\" THEN path$=LEFT$(path$)
      SYS "FindFirstFile", path$, dir% TO sh%
      IF sh%<>-1 THEN SYS "FindClose", sh% ELSE = 0
      = ((!dir% AND 48)-24) / 8

The first routine is a local routine for the program. Two and three are my standard library routines. It does seem slightly inefficient to have the second two separate, but there are (or at least were) good reasons for this. If it is this, it's never caused me a known problem before.

Matt