locked
strange behavior RRS feed

  • Question

  • Win XP / Access 2003

    I'm experiencing some strange behavior. I'm currently in the middle of adding user permission functionality. Until I get it all worked out I'm simply maintaining the Access .mdw security and permissions previously established. So here's what's happening:

    1. I login via the Access .mdw security.
    2. The form set to open in the startup is MY security login form. For some reason, this simple form that has two comboboxes that lookup user info "hangs" a bit.
    3. After selecting a user and entering in the password the login form goes invisible and then the main menu opens.

    At this point the database drags and hangs. I then compact and login again via MY login form. All is well. The database zips along just fine.

    Why does the database hang at my login form? And then why does compacting un-hang things?

    Any ideas?

    Tuesday, November 23, 2010 2:16 PM

Answers

  • Good grief!!! I found what was causing the hang-up. My FE somehow became un-secured!!! I can't imagine how I did that!

    Since I didn't know it was un-secured AND was opening it via the shortcut that targets the .mdw file AND it was linking to the secured BE - well, that's what was making it hang.

    I re-secured the FE and BINGO! No more hanging.

    This is without a doubt the STRANGEST day I've ever had!

    • Marked as answer by JohnLute Wednesday, November 24, 2010 2:37 AM
    Wednesday, November 24, 2010 2:37 AM

All replies

  • John,

    This can be diffcult one to diagnose - it sounds like what you're seeing is some sort of cache-hit/miss thing (the first time you open is a miss, the 2nd is a hit)...Even stepping thru the code can slow things down sufficiently to resolve the delay issue you're seeing if it is a file-based/db-based delay.

    Are you using a bound form or VBA code to do your security stuff? (I'm betting VBA)...if it is VBA, then your best option to diagnose this is to sprinkle a bunch of Debug.print statements into your code at strategic locations before & after your file/DB operations and watch the immediate window for what is/was going on when it seems to "hang up"...especially on that "initial startup" sequence.

    Sorry I can't give you anything more specific than this advice.


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Tuesday, November 23, 2010 2:55 PM
  • Hi, Mark. Yes - my login form is bound to one simple table. Thanks for your input. I'll wait to see what others might say and then try to arrive at some kind of approach.
    Tuesday, November 23, 2010 3:02 PM
  • Wait a sec... your login FORM is bound to a TABLE?

    ...are you sure that's what you want? ...or did you mean to say that those two combo boxes are bound (but the FORM is not)...? just trying to be clear (I would never bind the login FORM myself).


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Tuesday, November 23, 2010 3:06 PM
  • Wait a sec... your login FORM is bound to a TABLE?

    ...are you sure that's what you want? ...or did you mean to say that those two combo boxes are bound (but the FORM is not)...? just trying to be clear (I would never bind the login FORM myself).


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)


    Yes - the login form is bound to the users table and only the username combobox is bound. The form's footer is set to invisible. A "Change Password" button becomes enabled when the login criteria is properly met. Upon clicking the Change Password button then the footer becomes visible and a user can then change their password which is a field in the bound table.

    Why wouldn't you bind the login form?

    Tuesday, November 23, 2010 3:19 PM
  • First, for Security reasons - if the form's underlying recordset is accessable, it's *HIGHLY* hackable.

    Second, for security reasons - the user authentication functions should be exclusive, and never combined with user data update functions (put those in a separate form accessible only after they log in successfully). The reasons for this are the same as reason #1.

    Third, does the combo-box navigate the form to the right record first? or does it update the first record all the time? (either way, these are functions which it should not be doing - see reason #1 again...)

    ...and if you don't think that it's a "real" security vulnerability, then just open your form, , hit ^g and type:

    ?forms(0).recordset.fields(0).name, forms(0).recordset.fields(0).value

    ...and see how hard it would be to retrieve that password by changing the fields(0) with another number...

    Then, if you think you're covered for that because you made ^g unavailable, open excel, hit ^g from there...and grab the open access session with "set oAccess= getobject("Access.application")"

    and then do ? oAccess.forms(0).recordset.fields(0).name, oAccess.forms(0).recordset.fields(0).value

    and tell me again how it's not highly vulnerable...

    If that still doesn't matter to you...ok. You just better hope they don't pick me to do a security audit of your apps at some point... :-)


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Tuesday, November 23, 2010 3:40 PM
  • First, for Security reasons - if the form's underlying recordset is accessable, it's *HIGHLY* hackable.

    Second, for security reasons - the user authentication functions should be exclusive, and never combined with user data update functions (put those in a separate form accessible only after they log in successfully). The reasons for this are the same as reason #1.

    Third, does the combo-box navigate the form to the right record first? or does it update the first record all the time? (either way, these are functions which it should not be doing - see reason #1 again...)

    ...and if you don't think that it's a "real" security vulnerability, then just open your form, , hit ^g and type:

    ?forms(0).recordset.fields(0).name, forms(0).recordset.fields(0).value

    ...and see how hard it would be to retrieve that password by changing the fields(0) with another number...

    Then, if you think you're covered for that because you made ^g unavailable, open excel, hit ^g from there...and grab the open access session with "set oAccess= getobject("Access.application")"

    and then do ? oAccess.forms(0).recordset.fields(0).name, oAccess.forms(0).recordset.fields(0).value

    and tell me again how it's not highly vulnerable...

    If that still doesn't matter to you...ok. You just better hope they don't pick me to do a security audit of your apps at some point... :-)


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)


    Mark,

    I suppose those are all legit points however Fort Knox security isn't required in the current environment.

    Tuesday, November 23, 2010 4:04 PM
  • I saw encountered some weird behavior recently.  I too would compact/repair and everything was fine, then when doing an import, had some problems.  Then it worked, then didn't.  I found out that, there were a few '-' hyphen marks in the data (in Excel).  I did a Ctrl+F, then replaced all '-' marks with zeros.  Maybe totally different from what you have, but the point is, check your data very carefully.  Access is quite finicky and it's throwing a fit because it doesn’t like something that you're doing.

    HTH,
    Ryan---

     


    Ryan Shuell
    Tuesday, November 23, 2010 4:11 PM
  • John,

    well then I have to wonder - if you don't really need decent security, then why have any at all? but that's your call to make of course.

    I just ask the nagging questions... ;-)


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Tuesday, November 23, 2010 4:32 PM
  • John,

    well then I have to wonder - if you don't really need decent security, then why have any at all? but that's your call to make of course.

    I just ask the nagging questions... ;-)


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)


    Define decent? Why create Fort Knox when it's not needed? It seems to me that "decent" is defined by what's needed.

    Tuesday, November 23, 2010 4:39 PM
  • Define decent?

    Ok - a "decent" level of security, IMO is a level of security ABOVE "childishly simple to crack" or "able to be bypassed easily" (e.g., the built in ULS/workgroup/.mdw and VBA project password security systems fail at this level of security).

    I'll go farther and even define your "fort knox" level of security in this scale too: "not able to be hacked or bypassed eithout significant effort, investigation, and/or time."

    A "decent" level of security can be achieved fairly easily and quickly (and without all that much effort). A "Fort Knox" level of security is signifcantly more difficult (though not entirely impossible) to engineer with an Access-based app.

    Of course, what you define as adequate may vary from my definitions. Indeed, my own definitions have evolved somewhat over time as well.


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Tuesday, November 23, 2010 5:39 PM
  • Good grief!!! I found what was causing the hang-up. My FE somehow became un-secured!!! I can't imagine how I did that!

    Since I didn't know it was un-secured AND was opening it via the shortcut that targets the .mdw file AND it was linking to the secured BE - well, that's what was making it hang.

    I re-secured the FE and BINGO! No more hanging.

    This is without a doubt the STRANGEST day I've ever had!

    • Marked as answer by JohnLute Wednesday, November 24, 2010 2:37 AM
    Wednesday, November 24, 2010 2:37 AM
  • Define decent?

    Ok - a "decent" level of security, IMO is a level of security ABOVE "childishly simple to crack" or "able to be bypassed easily" (e.g., the built in ULS/workgroup/.mdw and VBA project password security systems fail at this level of security).

    I'll go farther and even define your "fort knox" level of security in this scale too: "not able to be hacked or bypassed eithout significant effort, investigation, and/or time."

    A "decent" level of security can be achieved fairly easily and quickly (and without all that much effort). A "Fort Knox" level of security is signifcantly more difficult (though not entirely impossible) to engineer with an Access-based app.

    Of course, what you define as adequate may vary from my definitions. Indeed, my own definitions have evolved somewhat over time as well.


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)


    Ultimately, isn't *any* security hackable? I will default to the "standard" and just design for what the immediate need is with enough vision to improve when/if necessary.

    My Windstar minivan was just recalled. The van has no real options or security beyond the standard door locks - don't really need more than that - it's decent. While I'm waiting for the repair I was given a LOADED 2010 Toyota Sienna. HOLY ____! This van has WAY MORE stuff than I'd ever need. Ridiculous how much ____ is in it. It's absolutely IN-decent!

    :)

    Wednesday, November 24, 2010 2:42 AM