Results 1 to 11 of 11
  1. #1
    Join Date
    Oct 2008
    Posts
    10

    Question Unanswered: Access 10023 on Server 2008 Problem - need help..

    Hi all..

    I'm running Access 2003 on Windows Server 2008.
    Usually, each user on the server runs an MDE file that runs my program
    (About 30 users +- simultaniously).
    This file runs automatically by defining it in the user's Environment Variables.
    When the user closes the program, the server end the session.

    When runs like that, some simple queries take forever to end, making forms o run unproperly (like sums not showing up etc.).

    The thing is, that if I check off the user's environment variables, enter the user's desktop, and run MDE file from there, it works perfect.

    Did anyone encounter this kind of problem? I really need the help..

    Thankx.

  2. #2
    Join Date
    May 2005
    Location
    Nevada, USA
    Posts
    2,888
    Provided Answers: 6
    What's the question? You already have your answer; each user should run their own copy of the MDE.
    Paul

  3. #3
    Join Date
    Oct 2008
    Posts
    10

    I will explain better

    First of all, thanks for the reply.

    Each user, of course, run its own copy of the MDE.
    I will explain the problem once again, in more detail:

    As an administrator of the server, I can set one of 2 ways for a user
    to log in:

    1. The user logs in and see his desktop, and he can run porgrams that he has permission to.

    2. The user logs in, but he doesn't see no desktop. His user properties are set to run only one file (The program's MDE) on log on, and log off when the program is closed.
    Like that:
    Click image for larger version. 

Name:	Noname.JPG 
Views:	29 
Size:	48.0 KB 
ID:	8836

    As far as I know, there is no essential difference between these options, a part from the fact that the user doesn't run the program by himself.

    But apparently I'm wrong because If I try the first option the program runs perfect, and if I'm using the other option, some forms run slow and make problems.
    Of course I must use the second option, so that the user won't be exposed to his desktop, and that way, won't even have a slight oppertunity to make any damage to the system.


    I hope this one better explained, and that you could help me,
    Thank you in advance, Ishay.

  4. #4
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    A suggestion that I might do is set it to run a specific program and have it run the script found here: http://www.dbforums.com/showpost.php...6&postcount=19 (and modify in the script the LUName line to point to your mde file.)
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Why not just add a shortcut to the program in the user's Startup folder?

    There are more than 2 ways... many more.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Quote Originally Posted by StarTrekker
    Why not just add a shortcut to the program in the user's Startup folder?

    There are more than 2 ways... many more.
    I guess that might depend on how globally he'd want to do this. If he did it on the server in the "logon" script (for all users), he wouldn't need to do it in every user's startup folder. If it's for a few users, then I'd go with your suggestion StarTrekker (I'd still point it to the "cloning the source mde" script.)

    Either way, I've never really messed with the user's Environment Variables but I'm guessing allocating memory versus free memory might have something to do with it. It usually does when you try to manually set those kind of variables as you're overriding the operating systems auto-configuration of them. With little memory left, it would make sense that queries might take a long-time (or never return a value) if no other changes have been made to how a user opens the mde.

    I did something similar to what Ishay is trying to do (although not with the same recordset size). I had the (all user's) logon script run the script to clone and launch the mde. And then made it so when they exited the mde, it continued to log them on or logged them out depending on which button they pushed in the mde (it was a timesheet login/logout application.) I did find that memory though played a factor on some old/little ram computers and ones where other programs had hogged all the memory.

    I then later just updated the backend tables in the vb script itself versus even having to open the mde file.
    Last edited by pkstormy; 10-10-08 at 19:48.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  7. #7
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Also keep in mind that using one of the Form Manipulation examples in the code bank, you can make an Access form "Full Screen" (with no Access bars showing - including covering the task bar at the bottom.) You may want to take a look at these examples if you want to keep the user from accessing their desktop while the Access mdb/mde is open.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    As I said... many ways

    I am a complete convert of the cloning VBS script too. A shortcut to that on each user's desktop is my "normal" now.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Did I convince you on the vb cloning script way StarTrekker?

    It's the one thing which has made my MSAccess development work sooo much easier in life (I've never dealt with a freakin "locked mdb/mde" issue since.)
    Last edited by pkstormy; 10-11-08 at 11:09.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  10. #10
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Totally convinced/converted and for every site I have changed over to use it, upgrades are a breeze and gone are those pesky locked file issues.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  11. #11
    Join Date
    Oct 2008
    Posts
    10
    Thank you guys, for all the information. I will try them and than come back with the results..

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •