none
File is in use by another...

    Question

  • Can editing a single row in a grid that is bound to a table - (not a cursor) trigger a "File is in use by another" for a different user trying to do a "replace" on a different row ?

    Also, does "unlock all" really release all locks in all areas?

    I'm trying to figure out why a form is causing a "file is in use by another" error and I don't think I'm doing anything locking the fie header...

    Any ideas how to diagnose this would be appreciated.

    Friday, April 5, 2019 3:14 AM

Answers

  • You think too much on the level of record and header locks VFP does. At any tiome only one process can write to any file, that's not the realm of any programming language.

    From that perspective you can get such errors in any situation two users write to the same file, no matter whether in separate roecords of a DBF or not, that "only on write handle" rule applies to whole files. Always. You also don't get around this witth working on different record of the file and thus by separate bytes of the file.

    In short that means even though you might avoid to do any header locks, the OS does file locks. That should now be understood.

    Regarding specifically VFP:

    If two users have a file open shared, before anyone writes changes you don't get File is in use by another user error, that error by definition opnly occurs when you open a file shared that's currently written to.

    So first question regarding that is: Are you sure about that exact error (108)? At which line does it happen and what are settings (SET REPROCESS, and buffering settings of dataenvironment and of the individual workarea. Such settings can override dataenvironment settings). 

    In a short experiment I do an endless loop of REPLACES (SO WHILE .T. REPLACE... ENDDO) I only get Record is in use by another user errors.

    The SET REPROCESS setting is most important, it depends what you do and what error handling is in place, a general error handler should have specific handling of error 108 and 109 with RETRY after a random wait time and opt out by user to stop try writing (instead of the system message with ESC to cancel, you get better control in your own handling)

    Besides that cable LAN usually is more stable, yes, but such errors also point to bad network configurations like for example write caching, as already mentioned. It's often condigured by network admins to lower network traffic by delaying it, this mechanism already is quite similar to oplocks in keeping changes local until finally some other client wants to read. In the hope writes to the same sectors accumulate and then can be transferred in one go.

    So especially once you're sue you ddin't just USE the DBF and got error 108 at that moment but at REPLACE, then you this points out somthing flaky in the LAN or Network cards or switches. Caution before you just network blame hardware and network settings, you might cause a reuse of files, you might cause an automatic header lock with tablebuffering at time of tableupdate.

    A help topic about locks also tells you which commands cause what automatic locking, on top of that you always have to keep in mind the OS and file system don't allow concurrent writing, not even per reserved sections in the same file. That's always the reason for multiple attempts.

    You can cause further problems with transactions, for example when you start them right after opening the DBF and not just accompanying writes to several DBFs you want to participate in the same transaction.

    Bye, Olaf.

    • Marked as answer by Aleniko2 Thursday, April 11, 2019 9:24 PM
    Friday, April 5, 2019 9:01 PM
  • The problem was caused by a "replace for" command which attempts to lock the header.

    I changed it to a scan replace block and all is good now.

    Thank you all.


    • Marked as answer by Aleniko2 Thursday, April 11, 2019 9:24 PM
    Thursday, April 11, 2019 8:08 PM

All replies

  • Yes, because of the basic rule of any file system only one handle can write at any time.

    Totally independent of foxpro.

    Even if you don't do any locks, there is automatic locking, only one user can write to a file at any time, independent on the programming language used, this is an OS level/file system level restriction.

    Andby the way, so many times not only I but every expert evangelizes about a general error handling, find out when the error occurs by what command exactly with ON ERROR. The example in the help already tells you to use the error sepcific functions ERROR(), MESSAGE(), PROGRAM(), LINENO() to see what error number/massage happens in which PRG or SCX or VCX method at what line number.

    If you then log errors or mail them or both you'd know when this happens, not necessarily why, but when. since you know you have unstable Wifi that can also just be another case of file not found, misinformation about the file because the connection is flaky.

    And no matter why it happens, when you find out it happens always in the same stage of eg USEing the table you could do a TRY at that place and handle the case it happens with a retry after waiting time, just like SET REPROCESS would also do, just under your own direction of how to wait, you might not just retry the USE of the DBF but a NET USE of a file share or opening of another file just with FOPEN and if you see the network is back again go back to USE the DBF.

    Or, as we discussed in your other thread, rather stay away from using a server side DBF at Wifi tablet clients and instead only rely on the fact you have times where you can read the whole DBF once and then work on the local copy, put iut back as separate new file in some kind of inbox folder and process it from there. That limits the wifi usage to reading once and putting back once, both processes can be done with retries and error handling unteil they worked error free and verifiably.

    This way you only use the connection at these "download" and "upload" times.

    Bye, Olaf.

    Friday, April 5, 2019 5:35 AM
  • Olaf;

    This is unrelated to the wifi connection questions. The system in question is all Gigabit wired, working perfectly fine all over the program.

    I am catching the error, and letting the user attempt again, and after some attempts it goes through.

    The problem seems to be happening when user 1 is editing a record in a grid (Which from my understanding should be a record lock). For some reason, when user 1 is editing a record, user 2 trying to do a replace in a different record will get a "File is in use" error, (which will be trapped, and re-attempted). 

    So to clarify - in a stable network environment, would editing a row in a grid cause a lock in which a different user cannot edit a different record?

    Thanks!

    Friday, April 5, 2019 5:58 PM
  • You think too much on the level of record and header locks VFP does. At any tiome only one process can write to any file, that's not the realm of any programming language.

    From that perspective you can get such errors in any situation two users write to the same file, no matter whether in separate roecords of a DBF or not, that "only on write handle" rule applies to whole files. Always. You also don't get around this witth working on different record of the file and thus by separate bytes of the file.

    In short that means even though you might avoid to do any header locks, the OS does file locks. That should now be understood.

    Regarding specifically VFP:

    If two users have a file open shared, before anyone writes changes you don't get File is in use by another user error, that error by definition opnly occurs when you open a file shared that's currently written to.

    So first question regarding that is: Are you sure about that exact error (108)? At which line does it happen and what are settings (SET REPROCESS, and buffering settings of dataenvironment and of the individual workarea. Such settings can override dataenvironment settings). 

    In a short experiment I do an endless loop of REPLACES (SO WHILE .T. REPLACE... ENDDO) I only get Record is in use by another user errors.

    The SET REPROCESS setting is most important, it depends what you do and what error handling is in place, a general error handler should have specific handling of error 108 and 109 with RETRY after a random wait time and opt out by user to stop try writing (instead of the system message with ESC to cancel, you get better control in your own handling)

    Besides that cable LAN usually is more stable, yes, but such errors also point to bad network configurations like for example write caching, as already mentioned. It's often condigured by network admins to lower network traffic by delaying it, this mechanism already is quite similar to oplocks in keeping changes local until finally some other client wants to read. In the hope writes to the same sectors accumulate and then can be transferred in one go.

    So especially once you're sue you ddin't just USE the DBF and got error 108 at that moment but at REPLACE, then you this points out somthing flaky in the LAN or Network cards or switches. Caution before you just network blame hardware and network settings, you might cause a reuse of files, you might cause an automatic header lock with tablebuffering at time of tableupdate.

    A help topic about locks also tells you which commands cause what automatic locking, on top of that you always have to keep in mind the OS and file system don't allow concurrent writing, not even per reserved sections in the same file. That's always the reason for multiple attempts.

    You can cause further problems with transactions, for example when you start them right after opening the DBF and not just accompanying writes to several DBFs you want to participate in the same transaction.

    Bye, Olaf.

    • Marked as answer by Aleniko2 Thursday, April 11, 2019 9:24 PM
    Friday, April 5, 2019 9:01 PM
  • The problem was caused by a "replace for" command which attempts to lock the header.

    I changed it to a scan replace block and all is good now.

    Thank you all.


    • Marked as answer by Aleniko2 Thursday, April 11, 2019 9:24 PM
    Thursday, April 11, 2019 8:08 PM