Results 1 to 14 of 14
  1. #1
    Bronze Lounger
    Join Date
    Jan 2001
    Location
    Virginia, USA
    Posts
    1,560
    Thanks
    37
    Thanked 1 Time in 1 Post

    Why does good code go bad? (A2K/SR1 and AXP)

    I've got this DB that's been working quite well, thank you. Fact is, I built this thing with a lot of help from the good people on this forum. One very useful feature is a form that lets the user enter an employee's payroll ID to lookup the employee's record, and then click on a command button to launch one of five reports that are available. All this was working fine till last Friday, which happened to be my day off, of course. I get a call at home begging for help. I had the caller switch over to a backup copy of the DB, which seemed to work. But when I return to work this morning, I have a message telling me that both the DB and the back-up DB had gone awry.

    Fortunately for everybody (but especially for me), I had yet another back-up stored in a secure location. Everything's fine now--or so it appears. But here's my question: What can make good code go bad? I did add another command button to this form last week, but I tested it afterwards, and it seemed to work fine. When I climbed into the wreckage this morning, I found a chunk of code just missing...gone! Does this kind of thing fall into the general category of "S*** happens"? <img src=/S/hmmn.gif border=0 alt=hmmn width=15 height=15> Is there a teensy bit of instability to code, or will the "black box" (de######) always point the finger of blame to pilot error?

  2. #2
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    I've never seen chunks of code disappear. I've frequently seen records in a table go corrupt, and I've seen forms becoming corrupt, but in that case they couldn't be opened any more in form view or design view, so the code behind the form couldn't be inspected. (I'm using Access 97, it might be different in Access 2000)

    Corruption of forms is often caused by several users having a form open at the same time. If you have split your database into a frontend and backend, and give each use his/her own copy of the frontend, that shouldn't occur. If all users use the same frontend, or if the database has not been split, you should take care that the users can't save the design of a form. Make sure the users can only close the form by running code (behind a button, menu option or whatever) that closes it without saving:

    DoCmd.Close acForm, Me.Name, acSaveNo

    This has eliminated corruption almost entirely in my Access 97 databases.

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    Unlike Hans, I *have* seen chunks of code disappear. It usually happens when errors cause the program to break into code and the user starts typing or merrily clicking away to try to get out and manages to delete chunks of the code along the way. I would get one of your users to walk you through what they were doing when the problems started and see if you can identify any possible errors that could cause this kind of thing.
    Charlotte

  4. #4
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    I second Charlotte's response - which is why a polished app should have a complete set of error handling routines and not allow the user to get into code. Error handling is a fairly complex topic, but one you should jump into. Also note that the comment about splitting the database if it isn't already is on target.
    Wendell

  5. #5
    Bronze Lounger
    Join Date
    Jan 2001
    Location
    Virginia, USA
    Posts
    1,560
    Thanks
    37
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    Hans, Charlotte and Wendell: I gather from your responses that it is indeed usually "pilot error" that leads to these problems. I'm just thanking myself for having kept a good backup copy of my DB.

    I like the idea of stepping through the situation with the operator, Charlotte. All I've heard so far is that they opened the db and went about their usual business and DOH! --it was busted! Well, maybe so.

    I still have not split this beast into a front end/back end. Aside from the abundant help I've gotten here, I'm pretty much self-trained in Access. It looks like it'll be pretty simple to do, but I gotta read up on it before to go there. Just a few months ago, when I'd see see a page of code in the VB Editor I'd just stare bug-eyed at it. Still do, some days. Thanks for the advice, everybody!

  6. #6
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    I just experienced something similar with one of my bosses today. He was destruction testing a next release and insisted it hung up Access and he had to use the Task Manager to close the application. I couldn't duplicate the problem until I watched him do something that was NOT exactly as he had described it. When I tried it the way he actually did it rather than the way he *said* he did it, I was able to duplicate the error and figure out where it was occurring.
    Charlotte

  7. #7
    2 Star Lounger bobdog's Avatar
    Join Date
    Jan 2001
    Posts
    108
    Thanks
    3
    Thanked 5 Times in 4 Posts

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    In addition to splitting the database, you might also distribute an MDE file, which contains no source code, to rule out accidental changes by users.

  8. #8
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    But an MDE without adequate error handling will cause even more grief and be harder to debug because you have to reproduce the error in the mdb instead.
    Charlotte

  9. #9
    Silver Lounger GARYPSWANSON's Avatar
    Join Date
    Aug 2001
    Location
    Frederick, Maryland, USA
    Posts
    1,788
    Thanks
    0
    Thanked 2 Times in 2 Posts

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    If error handling is not used and an MDB is distributed, would it be of any value to password protect the VB code such that the user would have to enter a pasword to get to the code?
    Regards,

    Gary
    (It's been a while!)

  10. #10
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    It might save your code from being trashed but it will still hang the user up and lead to irate phone calls. Error handling is absolutely essential.
    Charlotte

  11. #11
    Bronze Lounger
    Join Date
    Jan 2001
    Location
    Virginia, USA
    Posts
    1,560
    Thanks
    37
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    Error handling...wow! I don't have a line of error handling in any of my stuff. Maybe that's the next thing I need to study.

  12. #12
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    Splitting your database is lots easier - there is a splitter wizard that wil pretty much do the job for you, though it's not difficult to do manually either. That way you may find that one or two people are the cause of the error that is occurring, and it's not as disasterous when only one person's front-end needs to be replaced. As to error handling, any of the good Access books will have a section on the concepts involved.
    Wendell

  13. #13
    2 Star Lounger bobdog's Avatar
    Join Date
    Jan 2001
    Posts
    108
    Thanks
    3
    Thanked 5 Times in 4 Posts

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    Sure, can't argue with that. You can always put back a copy of the mdb for debugging purposes.

    You say you put front-end mdb's containing source code in user hands? I don't, unless it's contractually a "for hire" project, and even then after user testing is done, everybody's happy and the bill is paid. Until that happens, I keep the source and distribute the mde. I guess if you're developing apps as an employee, it's a different story, but it doesn't seem wise if you're a contractor.

    Payment issues aside, distributing a front-end mdb is an open invitation to a lot of system types and beginners looking for code. Seems like you want to secure the application to rule out meddling, if for no other reason.

    Anyway, happy holidays.

  14. #14
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Why does good code go bad? (A2K/SR1 and AXP)

    As a contractor, I'm on a pay-as-you-go schedule, so everything I give them they pay for. I am also employed by a company that markets software to a particular industry around the world, but we use Access security to keep users from mucking about with our code. In a pinch, we can walk an admin level user through a band-aid by phone and then send them a properly patched and tested version within a few days.
    Charlotte

Posting Permissions

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