locked
Desktop shortcut to .mdb .adp on network share fails to open. Pointer changes to Hourglass (Spinner) briefly and does nothing RRS feed

  • Question

  • Normally, users with Windows XP and the Access 2007 runtime client use a desktop shortcut pointed to a network share to load both .mdb and .adp files. As users upgrade to Windows 7 machines the desktop shortcut .lnk fails to load the application. The mouse pointer changes briefly to an Hourglass-spinner but nothing happens and there is no error message. Users with full MS Access and Win 7 can start MS Access then open the .mdb or .adp files using file/open dialog. Unfortunately runtime users don’t have a file open option.

    The .mdb and .adp files are located on a shared server path. The MS Access files have VBA code and connect to SQL server. The server arrangement is corporate class with domain controller, exchange and file servers in a virtualized environment.

    Assuming a macro security issue I have tried exporting/importing registry settings for MSO trusted network path locations from a working machine. Over time the shortcuts mysteriously or intermittently work. It is possible that registry tampering, installing windows updates, or loading the application once within a session help. Installing XP mode appears to resolve the problem but is not a practical solution. Any ideas?

    Monday, October 10, 2011 4:42 PM

Answers

  • A new piece of information, it looks like the Windows 7 shortcut works when the Windows 7 machine is first. Execution fails for all subsequent users with Windows 7. My thought is that is related to Access exclusive shared mode stuff. The problem exists when trying to open through explorer as well. Regular EXE files don’t have the same problem.


    Sounds like the file is opening write, exclusive instead of write, shared, unfortunately  I don't know any way to change that.

    Updating the files in a .cmd or .bat file is easy use xcopy with the /d option to only copy newer files: xcopy <source> <destination> /d /q

     

    xcopy \\server\public\*.* c:\temp\ /d

     

    The /q is optional, it turns off some of the copy messages

     


    • Edited by Rick Macmurchie Tuesday, October 11, 2011 8:32 PM
    • Marked as answer by Leo Huang Wednesday, October 19, 2011 4:20 AM
    Tuesday, October 11, 2011 8:32 PM

All replies

  • It is not possible to upgrade directly from Windows XP to Windows 7. Organizations that want to move
    users from computers running Windows XP to Windows 7 need to consider migration. So the application cannot work correctly on user's Windows7 OS. For more information, you can have a look at MCTS 70-680:Configuring Windows7 course.

    Monday, October 10, 2011 5:43 PM
  • I think you may be on the right track with it being a security issue.

    I can think of two things you could try...

    Since it sounds like the data is in a SQL database instead of the mdb, try copying the files to the local machine instead of leaving them on the network share, it makes it a pain to roll out updates but it may allow it to run.

    You could also try turning off UAC or launching as Administrator to see if the problem is related to the limited privleges in Windows 7

    Also, check the system andapplication logs, since the launch is silently failing, it may be logging an error.

    Monday, October 10, 2011 7:41 PM
  • Hi Rick,

    I am trying to avoid the using local copy. Although, executing through batch file that compares versions and makes a local copy if needed may be the best way to manage the pain of rolling out updates. I’m not fluent in command line work so don’t know how hard that would be.

    The UAC did not help but I learned where those aggravating warnings come from. Thanks.

    I can’t find anything related in the Event Log.  

    A new piece of information, it looks like the Windows 7 shortcut works when the Windows 7 machine is first. Execution fails for all subsequent users with Windows 7. My thought is that is related to Access exclusive shared mode stuff. The problem exists when trying to open through explorer as well. Regular EXE files don’t have the same problem.

    I found an unresolved discussion that for the same problem. Policy settings end up not being the reason as suspected in the beginning of the thread.  Access databases on network won't open via shortcuts or explorer

    Thanks.


    • Edited by thesnide1 Tuesday, October 11, 2011 4:10 PM
    Tuesday, October 11, 2011 4:07 PM
  • I have decided to go with the batch file idea where the local file is compare to the server file. If version is different a local copy is made before executing. I started with a batch file example created by RossWindows at Check version of MS Access with Batch File

    http://www.access-programmers.co.uk/forums/showthread.php?t=147346

     

    Thanks for your comments.

     

    Tuesday, October 11, 2011 7:17 PM
  • A new piece of information, it looks like the Windows 7 shortcut works when the Windows 7 machine is first. Execution fails for all subsequent users with Windows 7. My thought is that is related to Access exclusive shared mode stuff. The problem exists when trying to open through explorer as well. Regular EXE files don’t have the same problem.


    Sounds like the file is opening write, exclusive instead of write, shared, unfortunately  I don't know any way to change that.

    Updating the files in a .cmd or .bat file is easy use xcopy with the /d option to only copy newer files: xcopy <source> <destination> /d /q

     

    xcopy \\server\public\*.* c:\temp\ /d

     

    The /q is optional, it turns off some of the copy messages

     


    • Edited by Rick Macmurchie Tuesday, October 11, 2011 8:32 PM
    • Marked as answer by Leo Huang Wednesday, October 19, 2011 4:20 AM
    Tuesday, October 11, 2011 8:32 PM
  • That link is about checking the version of access, not the version of the data file.

    The xcopy /d command compairs the file dates of the source and destination and copies only if the source is newer.

    I think you will be wanting to check that you have the latest copy of the mdb each time you start, a single xcopy command should do the job.

    Wednesday, October 12, 2011 12:23 AM