locked
File access is denied when we use Copy To RRS feed

  • Question

  • Try to write my Problem generate when we use Copy To

    **********************************************

    ** In main menu (top level)

    ** I am using gcTmpFile variable many times in menu related Programs files for Data Copy and Append From.  (as dummy file)

    PUBLIC gcTmpFile

    gcTmpFile = SYS(2023)+'\'+SYS(2015)+'.TMP'

    .

    .

    .

    Use <file> Index <file> Order <order> Share Again

    Set Key to <key>

    Go Top

    COPY TO &gcTmpFile FIELD DATE, BILLNO, QTY, FREE ...etc.

    Here, some times Error generate: File access is denied C:\Temp\_3nt0q1fp3.tmp. 

    Approx: 10 times in 1000 times using..

    Note: gcTmpFile never opened by USE, only using Copy to and Append From purpose

    *******************************************

    in VFP9 - any command to find out that File is used by another process i.e. Virus, windows

    How to solve this problem ?



    • Edited by A.Ankit Monday, December 24, 2012 5:35 PM
    Monday, December 24, 2012 3:49 PM

Answers

  • SYS(2015) doesn't necessarily return a unique string. Maybe the problem is that you're already using that file name. Try using a loop like this:

    gcTmpFile = FORCEPATH(FORCEEXT(SYS(2015), "TMP"), SYS(2023))
    DO WHILE FILE(m.gcTmpFile)
       gcTmpFile = FORCEPATH(FORCEEXT(SYS(2015), "TMP"), SYS(2023))
    ENDDO

    Also, as a matter of good practice, don't us a macro in that COPY TO line. Use parentheses instead, so that if there's a space in the path, you won't crash:

    COPY TO (gcTmpFile) FIELD DATE, BILLNO, QTY, FREE 

    Tamar

    • Proposed as answer by Naomi N Monday, December 24, 2012 9:23 PM
    • Marked as answer by Youen Zen Friday, January 4, 2013 5:28 AM
    Monday, December 24, 2012 9:07 PM
    Answerer
  • >I have already checked that TempFile is NotExist and should not be SameName

    Well, under which conditions? When you test alone?

    SYS(2015) is guaranteed to create unique return values, but only for a single process. If multiple users create file names via SYS(2015) they can produce the same name. You have to check not only during development, but at runtime with the code tamar gave, that the file name you plan to generate doesn't exist, better yet you have to catch that error and then at the moment it happens create another SYS(2015) name, because even when using Tamars check

    DO WHILE FILE(m.gcTmpFile)
       gcTmpFile = FORCEPATH(FORCEEXT(SYS(2015), "TMP"), SYS(2023))
    ENDDO

    that is only valid at that moment and the moment you COPY TO another user could also have generated that same name.

    Another reason you get your error is, you reuse the gcTmpFile value after it's first use, you always have to call SYS(2015) to create a new unique, unused temp name before you COPY TO.

    Bye, Olaf.

    PS: There is a much simpler concept to create temp data: Cursors. Simply SELECT DATE, BILLNO, QTY, FREE FROM sourcetable WHERE keyfield = keyvalue ORDER BY .... INTO CURSOR tempcursor READWRITE and you have that data in a cursor, you won't have to care for unique names, VFP does that on it's own, you can reuse the same cursor name and VFP overwrites it.

    • Edited by Olaf Doschke Thursday, December 27, 2012 1:01 PM
    • Marked as answer by Youen Zen Friday, January 4, 2013 5:28 AM
    Thursday, December 27, 2012 12:57 PM

All replies

  • Check if you have access to write on the temp directory.

    Modify the security level of the user which you are logged into the computer and give full access

    Make sure he is not using a pre-existing file and not the new one (generated)

    You can also delete the temp directory and check next time you run the process if creates the file.


    • Edited by Benny Gabel Monday, December 24, 2012 5:42 PM
    Monday, December 24, 2012 5:41 PM
  • SYS(2015) doesn't necessarily return a unique string. Maybe the problem is that you're already using that file name. Try using a loop like this:

    gcTmpFile = FORCEPATH(FORCEEXT(SYS(2015), "TMP"), SYS(2023))
    DO WHILE FILE(m.gcTmpFile)
       gcTmpFile = FORCEPATH(FORCEEXT(SYS(2015), "TMP"), SYS(2023))
    ENDDO

    Also, as a matter of good practice, don't us a macro in that COPY TO line. Use parentheses instead, so that if there's a space in the path, you won't crash:

    COPY TO (gcTmpFile) FIELD DATE, BILLNO, QTY, FREE 

    Tamar

    • Proposed as answer by Naomi N Monday, December 24, 2012 9:23 PM
    • Marked as answer by Youen Zen Friday, January 4, 2013 5:28 AM
    Monday, December 24, 2012 9:07 PM
    Answerer
  • Thanks for your guide lines.

    (but, I have already checked that TempFile is NotExist and should not be SameName)

    Maybe, not problem with FileName or security level of the user.

    With my knowledge - either Virus Program or Window accessing problem.

    ***********************************************************

    Any function in Window API, WMI to find out - File is using in another process - to avoid the error (File access is denied) ?

    Tuesday, December 25, 2012 6:34 AM
  • llSuccess = .F.
    FOR lnI = 1 TO 10
      TRY
        COPY TO &gcTmpFile FIELD DATE, BILLNO, QTY, FREE ...etc.
        llSuccess = .T.
      CACTH
      ENDTRY
      IF m.llSuccess
        EXIT
      ENDIF
      WAIT WINDOW "Next copy attempt delay" TIME 0.5
    NEXT
    
    IF !m.llSuccess
      *-- Copy failed
    ENDIF
    

    Tuesday, December 25, 2012 10:59 AM
  • Try    ?GETENV("TEMP")    or    cd GETENV(TEMP), see what directory returns.

    Also you can right click on the directory and check if is readonly

    Tuesday, December 25, 2012 12:29 PM
  • >I have already checked that TempFile is NotExist and should not be SameName

    Well, under which conditions? When you test alone?

    SYS(2015) is guaranteed to create unique return values, but only for a single process. If multiple users create file names via SYS(2015) they can produce the same name. You have to check not only during development, but at runtime with the code tamar gave, that the file name you plan to generate doesn't exist, better yet you have to catch that error and then at the moment it happens create another SYS(2015) name, because even when using Tamars check

    DO WHILE FILE(m.gcTmpFile)
       gcTmpFile = FORCEPATH(FORCEEXT(SYS(2015), "TMP"), SYS(2023))
    ENDDO

    that is only valid at that moment and the moment you COPY TO another user could also have generated that same name.

    Another reason you get your error is, you reuse the gcTmpFile value after it's first use, you always have to call SYS(2015) to create a new unique, unused temp name before you COPY TO.

    Bye, Olaf.

    PS: There is a much simpler concept to create temp data: Cursors. Simply SELECT DATE, BILLNO, QTY, FREE FROM sourcetable WHERE keyfield = keyvalue ORDER BY .... INTO CURSOR tempcursor READWRITE and you have that data in a cursor, you won't have to care for unique names, VFP does that on it's own, you can reuse the same cursor name and VFP overwrites it.

    • Edited by Olaf Doschke Thursday, December 27, 2012 1:01 PM
    • Marked as answer by Youen Zen Friday, January 4, 2013 5:28 AM
    Thursday, December 27, 2012 12:57 PM