Results 1 to 12 of 12
  1. #1
    Join Date
    Apr 2007
    Posts
    108

    Unanswered: Killing off the record navigation in a form?

    I want to prevent users from navigating through all the records when viewing a particular form!

    I am aware of RecordNavigation property that does the trick only partially by removing record navigation buttons, although the user can still scroll to next or previous record by means of mouse scroll button or PgUP and PgDown!

    I'm also aware of AddData, RecordSet and similar properties that limit the number of records displayed but the form,

    BUT

    IS THERE A WAY TO TAKE COMPLETE CONTROL OF RECORD NAVIGATION, what events should I be catching?

    Thanks!

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    COMPLETE CONTROL = unbound forms
    ...you-the-coder own absolutely everything: every process; every control; every record; every event.
    ...you-the-coder also must code absolutely everything or nothing happens at all. you fill the form with your choice of record (hopefully somehow in line with the user's intention ), you harvest the user's edits, you save them where you want after you have verified that they merit being saved. there is no next record to scroll to unless you decided to provide it.

    it's a mindset.
    some folk say that going unbound strips 90% of the vitamins out of Access...
    i don't care and use unbound for any app that i release to my unfortunate users. i keep bound for quick&dirty utilities with me as only user. be aware: unbound forms double development time even after you are used to the idea.

    corollary: if you don't take full control with unbound forms, Access will take control when you least expect it and will always choose the stupid option that you didn't anticipate.

    unbound-izy
    currently using SS 2008R2

  3. #3
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Ther's a property somewher which is all about record scrolling - set it to "This one only"...
    The properties you want are ther, you're just not looking hard enough

    Oh and I'm with Izy - unbound is always the best way
    George
    Home | Blog

  4. #4
    Join Date
    Apr 2007
    Posts
    108
    Thanks for the replies!

    I always like a well-argumented rant especially with the touch of philosophy izy!

    Going unbound sounds a bit too extreme for needs of my 3 form application!

    Anyway it leaves a bitter taste that they couldn't incorpofrate OnNext; OnLast etc. events in forms!

    You are still left with the options to kill of recordnavigators, intercept mouse scrolls and PgDowns.

  5. #5
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Going unbound for 3 measly forms is easy peasy

    This is going to become my motto soon...
    "Do it right once and quit your worrying"
    George
    Home | Blog

  6. #6
    Join Date
    Apr 2007
    Posts
    108
    Ok, what do you use to submitt data entered into unbound forms to tables?

  7. #7
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    erm...
    press this button to add a record
    press this button to delete a record
    press this button to edit this record
    press this button to save changes

    controls are locked unless required for edits or additions
    pressing the relevant button forces the user to be more disciplined

    using this design paradigm also stops the nasty data errors that are part and parcel of a standard Access app.. whereby the user inadvertently clicks something and without realising changes something.. if you move off that record Access trying to be helpful saves the changes. The user denies all knowledge of the changes (because they don't know they made changes), your application is called into question. unless you then put in a do you want to save changes on the forms before update. Mind you if you were alos running an audit log then you as developer are playing a version of Cluedo, except you know who did the dirty deed (what userid), what they did it with (which computer) and when (the date and time of the event). So its not your neck on the line.. running an audit log allows the developer to sleep easier at night, using unbound controls allows the developer to sleep easier.. there is less chance of data corruption or users doing things they are not entiotled to do. you can incorporate your security at the form level aswell with a simple call to the security module requesting if that user as appropriate clearances for that form and the proposed action

  8. #8
    Join Date
    Apr 2007
    Posts
    108
    Izyrider do you have some "Crash course on going unbound" readily available to share with us!

  9. #9
    Join Date
    Apr 2007
    Posts
    108
    erm...
    press this button to add a record
    press this button to delete a record
    press this button to edit this record
    press this button to save changes
    I'm aware of that part, I was thinking more about how I put a lot of unbound values (textboxes, toggle buttons, list picks) etc. into a particular table?

  10. #10
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    unlock the controls
    allow the user to fill with whatever values they choose
    validate those values
    if acceptable issue an update.

    whether you do that as an SQL update statement (inmhv the better), or a vba update is your choice.

    either as part of your validation checks check any RI constraints or issue the update and trap for any errors
    decide what to do with any errors

    so have a look int he helpfile for how to execute SQL statements,, have a look at recordsets ADO or DAO doens't matter that much, have a look at things like docmd.execute

    have a look at the update SQL syntax
    have a look at error trapping

  11. #11
    Join Date
    Apr 2007
    Posts
    108
    Thanks healdem valuable pointer in the right direction!

  12. #12
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    Riorin:

    demo posted in the CodeBank

    izy
    currently using SS 2008R2

Posting Permissions

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