Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Access security glitch

Discussion in 'Information Technology' started by ginnyk, Jul 28, 2006.

  1. ginnyk

    ginnyk
    Expand Collapse
    Guest

    I have a client using an mde created in 1999 by someone else, for
    which I don't have the original source. There is a workgroup file that

    accompanies the mde file. I have the user and password information
    required by the workgroup file.
    In 2004 the client requested changes. Without the source, I
    couldn't make the change to the mde file itself, so I wrote a small mdb

    that attaches tables and provides a form to fulfill the client's new
    requirements. I created a shortcut for the new mdb that includes the
    workgroup info, and for 2 years everything has worked fine.
    Suddenly, the client is getting permission errors whenever he
    attempts to access his data. He can open my tool mdb, but not the
    tables attached to it. As it works fine when re-installed on my
    desktop, I figured his copy of the workgroup file had been corrupted or

    overwritten. I sent him a replacement, but it didn't help.
    Any ideas on where the permission errors might be coming from would
    be greatly appreciated.
     
  2. Loading...


  3. Jerry Whittle

    Jerry Whittle
    Expand Collapse
    Guest

    The first things that I would check are the drive mappings or file/folder
    permissions. Somebody could have messed with them. Next I would relink the
    attached tables.
    --
    Jerry Whittle
    Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.

    "ginnyk" wrote:

    > I have a client using an mde created in 1999 by someone else, for
    > which I don't have the original source. There is a workgroup file that
    >
    > accompanies the mde file. I have the user and password information
    > required by the workgroup file.
    > In 2004 the client requested changes. Without the source, I
    > couldn't make the change to the mde file itself, so I wrote a small mdb
    >
    > that attaches tables and provides a form to fulfill the client's new
    > requirements. I created a shortcut for the new mdb that includes the
    > workgroup info, and for 2 years everything has worked fine.
    > Suddenly, the client is getting permission errors whenever he
    > attempts to access his data. He can open my tool mdb, but not the
    > tables attached to it. As it works fine when re-installed on my
    > desktop, I figured his copy of the workgroup file had been corrupted or
    >
    > overwritten. I sent him a replacement, but it didn't help.
    > Any ideas on where the permission errors might be coming from would
    > be greatly appreciated.
    >
    >
     
  4. ginnyk

    ginnyk
    Expand Collapse
    Guest

    Jerry Whittle wrote:
    > The first things that I would check are the drive mappings or file/folder
    > permissions. Somebody could have messed with them. Next I would relink the
    > attached tables.
    > --
    > Jerry Whittle
    > Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
    >

    Those are good ideas, thanks, but 1) it's a local installation, so
    there should be no drive mappings or file/folder permissions, and 2)
    the original mde, which attaches the same tables, is working fine.
    Besides, wouldn't that be a 'file or path not found' error, rather than
    'you don't have permission...'?
     
  5. dbahooker@hotmail.com

    dbahooker@hotmail.com
    Expand Collapse
    Guest

    MDB is crap..

    throw it away and rewrite it in access data projects.

    spit on anyone that tells you otherwise.



    ginnyk wrote:
    > Jerry Whittle wrote:
    > > The first things that I would check are the drive mappings or file/folder
    > > permissions. Somebody could have messed with them. Next I would relink the
    > > attached tables.
    > > --
    > > Jerry Whittle
    > > Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
    > >

    > Those are good ideas, thanks, but 1) it's a local installation, so
    > there should be no drive mappings or file/folder permissions, and 2)
    > the original mde, which attaches the same tables, is working fine.
    > Besides, wouldn't that be a 'file or path not found' error, rather than
    > 'you don't have permission...'?
     
  6. ginnyk

    ginnyk
    Expand Collapse
    Guest

    Jerry Whittle wrote:
    > The first things that I would check are the drive mappings or file/folder
    > permissions. Somebody could have messed with them. Next I would relink the
    > attached tables.
    > --
    > Jerry Whittle
    > Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
    >

    Those are good ideas, thanks, but 1) it's a local installation, so
    there should be no drive mappings or file/folder permissions, and 2)
    the original mde, which attaches the same tables, is working fine.
    Besides, wouldn't that be a 'file or path not found' error, rather than
    'you don't have permission...'?
     
  7. ginnyk

    ginnyk
    Expand Collapse
    Guest

    dbahooker@hotmail.com wrote:
    > MDB is crap..
    >
    > throw it away and rewrite it in access data projects.
    >
    > spit on anyone that tells you otherwise.
    >

    Not a very useful suggestion, but thanks for your time
     
  8. dbahooker@hotmail.com

    dbahooker@hotmail.com
    Expand Collapse
    Guest

    Access doesn't give the best, most concise information sometimes.

    Do you have create permissions in the directory where it lives?
    when you open a MDB file it creates a lock file with LDB extension.

    -Aaron


    ginnyk wrote:
    > Jerry Whittle wrote:
    > > The first things that I would check are the drive mappings or file/folder
    > > permissions. Somebody could have messed with them. Next I would relink the
    > > attached tables.
    > > --
    > > Jerry Whittle
    > > Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.
    > >

    > Those are good ideas, thanks, but 1) it's a local installation, so
    > there should be no drive mappings or file/folder permissions, and 2)
    > the original mde, which attaches the same tables, is working fine.
    > Besides, wouldn't that be a 'file or path not found' error, rather than
    > 'you don't have permission...'?
     
  9. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest

    Do you use a shortcut to specify which workgroup file, or do you have to
    'join' a particular workgroup?

    If the user changed workgroups, created a new one, or joined a different
    one, then that would explain the sudden change.

    All normal, and regular mdb/mde files would work, except the one that is
    secured.

    The above is a good reason why *most* of us when using workgroup security
    files ALWAYS setup a shortcut (that way, the user does not have to be joined
    to a particular workgroup BEFORE the appcation is launched. And, if the user
    joins a different workgroup, then again our short will solve this problem).

    So, I would check if the user changed the workgroup file, or perhaps joined
    a different workgroup file, or even more likely even created a new group
    file. Simply sending them a workgroup file does nothing if you don't have a
    shortcut that points to this new workgroup file, or they use the security
    menu, and join this workgroup file that you sent them. They might follow
    your instructions to place the workgroup file you sent them into the
    directory where the "old" workgroup file is..but, that is meaningless if
    they joined some other workgroup file on the hard disk....

    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     
  10. ginnyk

    ginnyk
    Expand Collapse
    Guest

    The shortcut target is:
    "C:\<path>\MSACCESS.EXE" "C:\<path>\cptool.mdb" \User<User> \Pwd<Pwd>
    "C:\<path>\cpdata.mdw"
    Except for the mdb name, it is the same target used for the cpdata.mde,
    that continues to work with no problems (so yes, sending a replacement
    mdw was a wasted effort). The tables that are attached to cptool.mdb
    are the same tables that are attached to cpdata.mde. I had the client
    send me his copy of the tool, so I could check if the permissions had
    been changed - they had not. It works as it should on my machines.

    I'm beginning to believe this has to be a communication error between
    myself and the client, as you suggest. It appears I have covered all
    the bases, that there is no mystery reason I hadn't thought of or
    didn't know about.

    Thank you for your time and effort.
     
  11. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest

    > The shortcut target is:
    > "C:\<path>\MSACCESS.EXE" "C:\<path>\cptool.mdb" \User<User> \Pwd<Pwd>
    > "C:\<path>\cpdata.mdw"


    I don't see a wrkgrp switch in the above??

    "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
    "C:\Documents and Settings\All Users\Application Data\Rides\RidesXP.mdb"
    /wrkgrp "C:\Documents and Settings\All Users\Application
    Data\Rides\Rides.mdw"

    note how I used the /wrkgrp switch, and I don't see that in your
    example.....

    Also, I never used \ (back slash) in place / (forward slash) ....do they
    even work??


    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     
  12. ginnyk

    ginnyk
    Expand Collapse
    Guest

    My fault. Typos. I'm wearing so many hats, it's beginning to put
    pressure on my brain. There IS a /wrkgrp switch, and all the switches
    have forward slashes.
     

Share This Page