none
Path not found errors occuring when linked database is located in C:\ProgramData folders RRS feed

  • Question

  • On Windows 7 machines, I am having intermittent problems when an Access application loads and attempts to open a connection to a local database. The code is caching database connections to several .mdb files in a global DAO.Database object. Windows XP machines have had no problem with this code for over 5 years.

    The .mdb file is located in a C:\ProgramData\ subfolder. Is there something about this location that needs special attention?

    Thanks!

    Patrick.

    Thursday, October 22, 2015 9:08 PM

Answers

  • >> Hope it is helpful.

    Regards & Fei <<

    Thanks Fei but we're not making any progress here because it's not really an Access problem. It has to do with Windows 7 being slow to provide network connectivity. Let's consider this discussion closed.

    Patrick.

    • Marked as answer by P Jackman Saturday, October 31, 2015 4:08 AM
    Saturday, October 31, 2015 4:08 AM

All replies

  • Hi Patrick,

    >>The .mdb file is located in a C:\ProgramData\ subfolder. Is there something about this location that needs special attention?<<

    No. ProgramData specifies the path to the program-data folder (normally C:\ProgramData). Unlike the Program Files folder, this folder can be used by applications to store data for standard users, because it does not require elevated permissions.

    You can get more detail about this folder from link below:
    ProgramData

    And for this issue, I suggest that you check the file whether exits.

    Hope it is helpful.

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, October 26, 2015 1:53 AM
    Moderator
  • Thanks Fei.

    The file exists. Oddly, if I introduce a loop for that attempted Open it will succeed on the second attempt 3 seconds later. Here is the caching block. The Case 1 file is in C:\ProgramData. Cases 2 & 3 are on mapped drives. Case 4 is also in ProgramData.

            For intI = 1 To mcMaxDatabases
                DoEvents
                Call SysCmd(acSysCmdUpdateMeter, intI)
                Select Case intI
                    Case 1:
                        strName = DictionaryPathFile()
                    Case 2:
                        strName = EmailMDB()
                    Case 3:
                        strName = FAXPathFileGet()
                    Case 4:
                        strName = SysMDB()
                End Select
                Set mdbOpen(intI) = DBEngine(0).OpenDatabase(strName)
                intErr = 0
            Next intI

    The loop is in the error handler.

        Select Case Err.Number
            Case cErrBadFileNameOrNumber, cErrPathNotFound, cErrCouldNotFindFile, cDiskOrNetworkError, cErrNotAValidPath, cErrFileAlreadyInUse
                intErr = intErr + 1
                If intErr < 5 Then
                    Call ErrorLog(Err.Number, Err.Description & "; Failed opening database " & strName & "; Wait=" & intErr & "; Init=" & vfInit, mcModuleName & ".OpenAllDatabase")
                    Call WaitForSeconds(3)
                    Resume
                End If
        End Select
        Call ErrorLog(Err.Number, Err.Description & "; Failed opening database " & strName & "; Wait=" & intErr & "; Init=" & vfInit, mcModuleName & ".OpenAllDatabase")
        Resume OpenAllDatabase_Exit

    Another odd thing: if Case 1 fails on the first attempt but succeeds on the second, Case 2 will always fail after 4 attempts to overcome Err 3044 "is not a valid path". The loop, for Case 2, is an attempt to wait-out slow drive mapping. It seems if there's an issue with network drive mapping, a file in ProgramData is momentarily not available. Can you think of any reason(s) for how these two observations might be related?

    Thanks!

    Patrick.



    • Edited by P Jackman Monday, October 26, 2015 5:12 PM
    Monday, October 26, 2015 5:10 PM
  • Hi Patrick,

    Thanks for the detail information for this issue.

    Can you reproduce this issue every time? If yes, I suggest that you try to repair and update the Access database to see whether the issue is fixed.

    If not, can you reproduce this issue update the link table manually?

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, October 28, 2015 8:54 AM
    Moderator
  • Thanks for offering your comments.

    The issue cannot be reproduced every time. It is affecting 0% of Windows XP users. It is affecting 14 of 25 Windows 7 users.

    The problem "appears" to be related to a delay in network connectivity after Win7 users login to Windows that results in drives not being successfully mapped during the login script. This would explain the "Path Not Found" error on network drives. It does not explain the "Path Not Found" error when a database file is located in the C:\ProgramData folder.

    Did you mean "Repair and Compact"? Yes, that's been done. Linking the table manually is not possible in a runtime environment.

    Thursday, October 29, 2015 4:49 PM
  • Hi Patrick,

    >>The problem "appears" to be related to a delay in network connectivity after Win7 users login to Windows that results in drives not being successfully mapped during the login script. This would explain the "Path Not Found" error on network drives. It does not explain the "Path Not Found" error when a database file is located in the C:\ProgramData folder.<<

    I am not able to under the scenario exactly. Did you mean that you were using script to login computer and execute the code to open the specific database and this issue is fixed if the database put in other path?

    If I understood correctly, to narrow down whether this issue is relative to use script to login computer, I suggest that you login computer manually and run the code to open the Access database.

    >>Did you mean "Repair and Compact"? Yes, that's been done. Linking the table manually is not possible in a runtime environment. <<

    Sorry for the confusing. I suggest that you repair the Access application to confirm whether this issue is relative to the Access application corruption.

    Hope it is helpful.

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, October 30, 2015 5:41 AM
    Moderator
  • >> Hope it is helpful.

    Regards & Fei <<

    Thanks Fei but we're not making any progress here because it's not really an Access problem. It has to do with Windows 7 being slow to provide network connectivity. Let's consider this discussion closed.

    Patrick.

    • Marked as answer by P Jackman Saturday, October 31, 2015 4:08 AM
    Saturday, October 31, 2015 4:08 AM