Results 1 to 11 of 11
  1. #1
    Monty51 is offline Advanced Beginner
    Windows XP Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    40

    Access user profile

    I thought I posted this request earlier, but since I can't find it, I'm assuming something went wrong, so here it is.

    I'm converting an Access DB from 2003 to 2016. I notice that the installation of the 2003 version of the app uses the /profile switch on it's command line. The profile (a lengthy hex string) leads to a registry entry where I can find the name of the app, the version, etc., that become part of the CurrentDB properties.

    I have no idea of the protocol for making this entry. I've found a few things on the Internet on how to create a profile, but they don't match the form of my profile entry (the hex string), so I'm asking for pointers to literature that can tell me how to create a profile for use with Access 2016.

    Right now I don't know how to put it any clearer than that. My knowledge is lacking on this.

    Thanks for looking.

  2. #2
    isladogs's Avatar
    isladogs is offline Very idle programmer
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,076
    I'm still not clear what you are asking but I'm fairly sure that using the /profile switch isn't the solution.
    I have never needed to use that command-line switch in over 20 years working with Access

    See Access command-line switches

    There are much simpler way of doing this type of thing. For example:
    a) to set 'items' such as name, version etc, you can do some of that from Access options or you can use a Settings table.
    b) to add properties, you can do that in code.

    If you can clarify exactly what you want, someone should be able to give you a better answer
    Colin (Mendip Data Systems): Website, email
    Try again. Fail again. Fail better.
    A
    sking for help isn't giving up. Its refusing to give up.

  3. #3
    Micron is offline Virtually Inert Person
    Windows 10 Access 2016
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    9,683
    does this help?
    https://support.microsoft.com/en-us/...e-5d2ef79439fa

    Note that if you convert to accde or accdb you lose all user level security features anyway. It might be worth noting that uls/workgroup file was deprecated with Access 2007 (?) anyway.
    - "doesn't work" doesn't help. Implement changes in copies of your database.
    Iím telling everyone it's good to eat dried grapes. Itís all about raisin awareness.

  4. #4
    Monty51 is offline Advanced Beginner
    Windows XP Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    40
    Ok, thanks for responding. I know it's all a bit vague, for which I apologize, but I'm figuring all this out as I go. I have an Access 2003 application (written by someone now deceased, and who didn't leave documentation) that uses the command line

    "C:\Program Files (x86)\Microsoft Office\OFFICE11\MSACCESS.EXE" "C:\Program Files (x86)\AeroClub\AeroCode.mdb" /user "aeroclub" /wrkgrp "C:\Program Files (x86)\AeroClub\AeroSystem.mdw" /profile "{4CA42DF7-0CD3-4D27-BAD2-3B72F165E8C2}" /runtime

    ...to start the app. The "/profile "{4CA42DF7-0CD3-4D27-BAD2-3B72F165E8C2}" part of the command line points to some registry settings that specify the app version, title, and other specific information that ends up in the list of properties associated with "CurrentDB" in the app. I'm converting the app to Access 2016 and I'm looking to decipher why the /profile has such a convoluted name so I can (hopefully) translate it to something maybe a little more sensible for Access 2016(?). I say that mostly ignorant of all the security ramifications and differences between Access 2003 and 2016. I know that user-level security isn't there in 2016 like it was in 2003 (unless I somehow stick with the .mdb format, but then, what's the point of upgrading?), but at this stage I'm just looking to dissect the importance of that /profile statement so I can determine if it's necessary to maintain that or can I go another route for getting that info into the DB's property list.

    Hope that's a little clearer.

    Thanks for looking

  5. #5
    Micron is offline Virtually Inert Person
    Windows 10 Access 2016
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    9,683
    IMO the value between the braces is either a GUID or a Replication ID but I'd go with GUID. Not because replication hasn't been supported since about version 2007 but because the GUID is likely a composite of several things, at least one of which ID's a users pc - possibly right down to the hard drive. That would make sense in terms of trying to keep non registered users out.

    IMO, if there is a need to convert you will need to look into other methods of employing security. What those are depends on how secretive the data is, how likely is it that anyone would be curious enough to meddle and the level of Access knowledge of those people. If data is very sensitive, Access may not the right tool for the job. You can thwart 99% of your users if you do it right and that may be good enough. The most security I ever needed to employ was a back end password, front end accde with most options disabled (e.g. shortcut menus, nav pane hidden, etc.) and shift click bypass property disabled. I kept nosy people out by maintaining a table of users where one field was their Windows log in ID, so it didn't matter what pc they were on. I also didn't allow registered users in if my code detected that the application path was not as expected (to prevent take home copies for example). AFAIK, all that worked - I even had supervisors from other departments call me to tell me they couldn't get in, which not only revealed that yes, Virginia, there are nosy parkers in the organization, but also that things were working as expected.

    Perhaps all you need to do is make the conversion but dispense with anything based on old Access security (part of which is the mdw file you mentioned). However, sometimes it is easier to start over than it is to remove/undo large chunks that are no longer needed; especially if security is being checked many times throughout your code project.

    EDIT - BTW, no one needs to point out to me that the be password can be discovered. I'm just saying it was good enough for us, especially when the other barriers are taken into account.
    - "doesn't work" doesn't help. Implement changes in copies of your database.
    Iím telling everyone it's good to eat dried grapes. Itís all about raisin awareness.

  6. #6
    isladogs's Avatar
    isladogs is offline Very idle programmer
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,076
    I agree. Scrap the MDW and start again.
    Do the conversion to ACCDB then add additional security whose scope is proportionate both to the sensitivity of the data and to the likelihood of tampering by the user base (both authorised and unauthorised).
    You may find my articles on security helpful e.g. Improve Security 2 - Mendip Data Systems
    Colin (Mendip Data Systems): Website, email
    Try again. Fail again. Fail better.
    A
    sking for help isn't giving up. Its refusing to give up.

  7. #7
    Monty51 is offline Advanced Beginner
    Windows XP Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    40
    I am scrapping the MDB/MDW approach to this app. I think, after having done some initial reading (more to do) that I'll be going the .accde route: it seems to offer sufficient native security, and then review other security built in to the app. The app requires a unique login and to my knowledge that has always been good enough, but there are some things mentioned I'd like to look into. The community accessing this app are more interested in flying (it's an app for tracking pilot hours and training at a flying school) then hacking and I know of no attempts to do so. The app runs on isolated networks so accessing the app from the Internet is not a concern.

    Regarding "but because the GUID is likely a composite of several things, at least one of which ID's a users pc - possibly right down to the hard drive", there is something in that approach I like, from a security standpoint. I'm going to try and look deeper into that. The string resembles other, similar entries in the registry, so I'm guessing there's a standard for it, so I have to try and find that. Maybe something in the installation process will tell me (I don't have the disk with me right now).

    Thanks for all the input, it's very helpful.

  8. #8
    isladogs's Avatar
    isladogs is offline Very idle programmer
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,076
    Working with GUIDs can be a real PITA If I were you, I would abandon that and focus on ensuring the ACCDE is fully functional with just enough security to meet your needs.
    Colin (Mendip Data Systems): Website, email
    Try again. Fail again. Fail better.
    A
    sking for help isn't giving up. Its refusing to give up.

  9. #9
    davegri's Avatar
    davegri is offline Excess Access
    Windows 10 Access 2016
    Join Date
    May 2012
    Location
    Denver
    Posts
    2,857
    Working with GUIDs can be a real PITA If I were you, I would abandon that and focus on ensuring the ACCDE is fully functional with just enough security to meet your needs.
    I certainly agree with that. GUIDs are a special kind of object for both Windows and Access. A GUID literal or variable (good luck with that) will react in unexpected ways in VBA.

  10. #10
    Monty51 is offline Advanced Beginner
    Windows XP Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    40
    Quote Originally Posted by isladogs View Post
    Working with GUIDs can be a real PITA If I were you, I would abandon that and focus on ensuring the ACCDE is fully functional with just enough security to meet your needs.
    I like the idea of the /profile approach, but yeah, it's looking like a real PITA the more I read on it, which is not much because I can't find the appropriate stuff on the Internet. It may just be a matter of knowing where to look, but I think I can use other methods to store the data the profile provides (app, title, user (which may not even be necessary any more), version, publisher, etc.), possibly in a restricted access table. I'd like to create a separate table for all that. The tables for this app are separate from the code (forms, queries, reports, VBA, etc.) and linked. If I can save the tables as a .accde file I'm hoping that will be enough to keep users from poking around in it.

    More and more reading...

    Thanks for looking.

  11. #11
    isladogs's Avatar
    isladogs is offline Very idle programmer
    Windows 10 Access 2010 32bit
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,076
    There is a reason why there is little info on GUIDs. They are extremely difficult to work with and often do not respond at all. I've sent too many fruitless hours investigating them.

    It is easy to store details such as app name, title, version number/date, author, username etc either in a settings table or as properties.
    If you want to use a table, then you need to determine how you will make it 'a restricted access table' using your own words.

    ACCDE files will automatically limit user access to certain features but by no means all.
    End users can still edit tables & queries. They can also write queries which may or may not be helpful.
    Anyone who is really determined can do far more unless you apply effective security measures.

    I'm hoping that will be enough to keep users from poking around in it
    No it isn't. That is why I recommended you read my security articles and others you may find online.
    Colin (Mendip Data Systems): Website, email
    Try again. Fail again. Fail better.
    A
    sking for help isn't giving up. Its refusing to give up.

Please reply to this thread with any new information or opinions.

Similar Threads

  1. Delete this profile
    By Perfac in forum Access
    Replies: 4
    Last Post: 02-26-2020, 11:41 AM
  2. Replies: 8
    Last Post: 10-11-2017, 10:43 PM
  3. Replies: 0
    Last Post: 06-02-2016, 11:41 AM
  4. /profile switch on Access
    By Perceptus in forum Access
    Replies: 0
    Last Post: 02-10-2015, 10:49 AM
  5. profile each user accounts?
    By jun90 in forum Access
    Replies: 1
    Last Post: 01-18-2010, 03:30 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums