Results 1 to 14 of 14
  1. #1
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140

    Unanswered: Forms not firing code?

    I upgraded this db I'm building from '97 to XP, now occasionally any (random) form appears not to run the code build behind it. I've put code breaks/step thrus in to check values at times to verify, and sure enough, the form goes blitzing past the breaks.

    Does this sound like an upgrade issue? (I've tried compacting and repairing...no difference) Or am I missing something obvious again?(It's Friday, I could very well be drain bamaged from the week).

    Thanks,

    Sam
    Good, fast, cheap...Pick 2.

  2. #2
    Join Date
    Sep 2002
    Location
    South Wales
    Posts
    580
    One thing you could check - go into the form/s in design view.

    On the form properties view, click the events tab and make sure your events are listed - if not click the ...to go to code view and save the form again.

    Do this for each event on the form - let us know whether this is the issue...
    Windows Server 2003-8 / Terminal Services / SQL 2000 / Access 2003 / Office 2003-7 / Exchange 2003-7 / Blackberry Enterprise Server / AutoCAD / Lambert And Butler / Red Bull

  3. #3
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Yep, my events are shown as [Event Procedure] in the properties list. If I click the ellipses, it does take me to the correct portion of my code.

    Mainly have code behind things like Form_Load() for the form, OnClick() for my buttons, and After_Update() for my comboboxes. Very seldom do I have anything as events for text boxes. I tend to do my validating after the onClick.

    I'm at a loss as to why some of these forms are acting wonky and others work great...sometimes the same form...just different times (and no edits to that form<sigh>). As a stopgap measure I've thrown some of the Form_Loads procedures into the Form_Activate, seems to have helped a bit.

    At over 5k lines of VBA and 40 unbound forms with queries encoded as control sources, I don't *want* to have to do a manual copy/paste/rebuild into a clean XP format from the one I imported (yes, I'm lazy<g>).

    However, if that's what I'm going to need to do to get Access to cooperate then I guess I can give 'er a whirl before I get too much further (I'm just shy of the halfway point on the build of this db).

    Thanks again and insight is welcome at this point. If we haven't got it figured by Tuesday I'll start transferring the stuff into a new db built as XP format instead of converted.

    Sam, back to my error checking..woohoo!
    Good, fast, cheap...Pick 2.

  4. #4
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Are you sure you've debugged/compiled the code (not just compact/repair the mdb?)

    Sometimes when I've seen this happen, there are functions which are named the same (this is what I find is often the problem with upgrades - it worked fine in the old code but the upsizing got confused.) Even if the function is in a different form, it should be named slightly different. Use the "Find" feature (select All Procedures) for function names to find functions named the same but in different forms/modules.

    I might also try creating a new mdb file (in the new XP version) and importing all the objects into that mdb, debug/compile the code!!, then compact and repair the mdb (that only takes a few minutes.) But make sure you debug/compile the code! (and do it IMMEDIATELY after importing! Don't import, change ANY code, and then debug/compile as this can cause problems.

    You may also want to open the mdb using the /decompile option (you do this using the RUN command from windows) See more info on this in the help or online. Then debug/compile, compact/repair.

    You can also look at your References. If a reference is missing, it's possible that other references aren't loading/executing due to a missing reference. You'll notice in your references there's an ADO reference (or possibly needs to have one.) For example, if you have a reference that uses something for Office 97, perhaps unchecking that reference and then checking the new reference version could help. Especially if you're using ActiveX controls (often a culprit - ie. the calendar control.)

    It could also be due to a 3rd party module which worked fine in 97 but XP doesn't like that module (ie. the mousewheel or other). If you have a few 3rd party modules, please respond with which 3rd party modules you may be using.

    Another thing I've done (as a last resort), is to create a new mdb and then start importing forms/modules 1 at a time (ie. import 1 or 2 forms, test them out, import another 1 or 2 forms, test them out, etc..etc..) This helps narrow down what could be a problematic form or duplicated function name (you could do the same with the modules if you have any.)

    I will often throw in a msgbox "I'm here in code" throughout several places in the code to determine where the code stops (It's a quick way to find out what code is/isn't executing and where there's a problem.) I even throw in a msgbox to relay any variable values (ie. msgbox "VariableX = " & VariableX.) I prefer this versus using the code breaks.

    If you're still having issues, you could zip and upload the mdb. Perhaps we can spot something you've missed. Otherwise, we can only throw out things for you to try without knowing how complex the coding actually is.

    I've seen a variety of reasons for code to stop working (even poorly named tables/field names.) For example, a field named: "Date" is an extremely poor naming scheme and often causes problems. Reserved names are a big no-no (ie. calling a field: "Name"). Field/Table names should never have spaces in them, never start with a number (ie. 3DateOfSomething), and of course, never have characters such as !@#$%^&(* in them.

    Lastly, I have to ask if you kept the 97 version of MSAccess on the same computer. MSAccess doesn't play well with different versions on the same computer (Microsoft does not recommend this and I've seen many problems with having 2 versions of MSAccess on the same computer.) Another example of a possible problem is things such as code based on things such as the delete code (done through the wizard.) The docmd.menuitem... might have worked fine in 97 but sometimes it's better to simply re-do the delete coding (using the wizard) for it to work with XP (since it's slightly different code.)

    Also keep in mind, if you've renamed any fields, even though you'll see the [Event Procedure], when you click the 3 dots (...), you'll notice the code is no longer there (since it's still based on the old field name.) Again, a simple msgbox can be a blessing for quickly spotting problems like this. Since you're using unbound forms, I'd start throwing in msgbox's in the functions you use to retrieve/update/delete the data.

    I wouldn't start changing events that used to work though (ie. OnLoad to OnActive.) This can cause results you don't really want since there's a reason the code was put in the OnLoad event versus the OnActive event.

    Another thing is the "Filter" command. I detest using this since there are often problems when it comes to a ' or " in the data itself. If you can pinpoint the code stopping when it happens to hit a specific record, then look for bad data in that record or data which could cause problems with the code. For example, a Date type field which has a date of 11/07 (versus 11/02/07) is often the culprit for coding to stop working and causing a developer to go crazy. I've often seen bad date values cause problems (where 97 might have overlooked this, XP says "I can't handle this value.") Date type fields are especially prone. Again, try to deduce a problem happening on a specific record when you encounter "It works most of the time but weirdly stops occassionally" type of problems. This is often a good sign that the coding doesn't work well with certain bad values or values with odd characters (again, more forgiving in 97 than XP.)

    Also (just thinking of possibilities), is if you've used DAO code for most of your coding (since ADO didn't really come into play until XP), MSAccess XP defaults to ADO so you could have issues with your DAO coding itself. (I personally highly prefer ADO over DAO - but there are a lot of hardcore DAO coders around who believe there's no other method - no offense - to each his own.) I just find ADO much easier to troubleshoot and code.

    With XP, MSAccess changed the way they saved forms (you probably noticed an increase in the size of the mdb after converting.) For some reason, it saves the form itself a little differently with XP (more overhead since XP compiles/saves the entire form unlike 97 did - I'm not sure on all the details about this (you'll have to read up on this), I just know it was a significant change on how forms are saved in XP - again, causing problems with functions named the same but in different forms.) Having a lot of functions in the form itself can take a toll. I try to keep most of my functions in modules and out of the forms themselves. With the new way XP saves forms, It'll keep your forms less problematic without having all your functions embedded in the form itself.
    Last edited by pkstormy; 09-05-09 at 01:37.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  5. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    I've seen code whip past all kinds of things when the code is wrong...
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I've also seen some MSAccess code not fire when (believe it or not) the print driver is not setup or there's no default printer!!

    Make sure you have the correct print driver or a default printer selected (ie. Start -> Control Panel -> Printers) on that computer.

    For some reason, MSAccess ties directly to the default printer.
    Last edited by pkstormy; 09-07-09 at 02:07.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  7. #7
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Good morning,
    Wow, thanks for the thoughts and suggestions. I'll take a look at the db today...but, right off the bat, I'm guessing you are probably spot on with the compile...for the life of me I can't remember compiling this in xp, so it could very well be the cause of my grief.
    No third party modules, but, plenty of (I'm assuming here) DAO commands. Is it a huge chore to go thru and change it from DAO to ADO? (Change a couple lines at each open/close? Or is it a "Change the whole freaking database design" kinda thing?) I've got no problems going thru and changing a few lines in each of the forms if that's all it's going to take.
    I'll try to strip out the company specific information in the thing and post it up. Never hurts to have someone else look at something and tell me if'n I'm on the right track or if it's a flaming ball of misery<g>.

    Thanks again for the insight, I'll post again here after I've tried your suggestions,

    Sam
    Good, fast, cheap...Pick 2.

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Good luck Sam
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Ok, I've gone thru and renames some methods (had multiple Clr_Frm() and verify_delete methods...grr...I shoulda known better).

    I've uploaded a copy of the db revised. If you have some spare time and notice something else that I've done bass ackwards I'd really appreciate a heads up. It's been a long time since I've done any Access work so I'm sure I've forgotten more than I knew.

    On the bright side, renaming and recompiling did seem to straighten out (and improve the speed) the code not firing issue...at least until I do something else boneheaded and have it blow up in my face again.

    After doing a little (very little) research, I'm fairly sure I'll be changing the format to be consistent with the ADO format instead of DAO...depends on how much time they give me to complete the rest of this project...still have the entire user side to build (the user forms that are in this thing are temporary...thrown together to have access something to fire while I was building the master switchboard form)

    Thanks again,

    Sam
    Attached Files Attached Files
    Last edited by SCrandall; 09-08-09 at 17:39.
    Good, fast, cheap...Pick 2.

  10. #10
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Why change? I have been using DAO exclusively for years and never had a problem with it. I personally don't see the sense in changing to ADO.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  11. #11
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    Yeh, after doing a bit more looking into it, unless I'm missing something, there really doesn't seem to be much of a difference between the two, so I guess the jury's still out on the switch.
    I generally like to switch to newer formats when I can for future support, but, doesn't really look like DAO's going to be going away any time soon. I guess we'll have to wait and see.

    Sam
    Good, fast, cheap...Pick 2.

  12. #12
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    I think there is so much legacy code in DAO that I doubt it will be dropped anytime soon. its not yet been deprecated by Microsoft so it should be good for another 3..5 years.

    I suspect if Microsoft bring out a .NET version of office products then I suspect that DAO will be on death row (and I suspect so to will ADO if the truth be told)

    In the late 90's I started to switch stuff to ADO, especially new stuff but looking in more detail it seemed the reasons for using ADO were more to do with talking to non SQL databases so it didn't seem of enough significance to drop DAO. I get the impression DAO is a lighter weight more focussed approach than ADO. now whether that's true or not is a moot point, but I prefer using DAO
    I'd rather be riding on the Tiger 800 or the Norton

  13. #13
    Join Date
    Mar 2009
    Posts
    5,442
    Provided Answers: 14
    Stick to DAO if you do not have a very good reason to change for ADO (working with stored procedures on a SQL server for instance), you'll spare yourself a lot of headaches and disapointments!
    Have a nice day!

  14. #14
    Join Date
    Aug 2009
    Location
    Up Nort' Wi
    Posts
    140
    LoL good to know. I guess I'll keep it as it sits then. (dang..and here I wanted to spend an extra x amount of hours banging my head against a wall for no good reason!<g>)

    Thanks for the input, as always appreciate everyone's opinions and experience.

    Sam, back to tweaking my "on the fly" reports...grr
    Good, fast, cheap...Pick 2.

Posting Permissions

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