Results 1 to 5 of 5
  1. #1
    2 Star Lounger
    Join Date
    Dec 2000
    Posts
    119
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Debugging strategy (A2K)

    Any suggestions for a debugging strategy when your code works if you step through it in debug mode, after a breakpoint, but fails if you just let it run (no messages or errors).

    TIA
    Donald

  2. #2
    3 Star Lounger
    Join Date
    Mar 2001
    Location
    Minneapolis, Minnesota, USA
    Posts
    262
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Debugging strategy (A2K)

    Carefully placed MsgBox that informs you where you are in the code? You might at least be able to determine that your code failed between, say, MsgBox 3 and MsgBox 4...

    Odd, though, the scenario you describe. Whatcha up to?
    <font face="Comic Sans MS"><font color=blue>~Shane</font color=blue></font face=comic>

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

    Re: Debugging strategy (A2K)

    Shane's suggestion is the one I usually use under those circumstances. It may be a timing issue if a network drive is involved, but I've usually found that the problem lay in the code itself and I've had to find alternate methods to do the same thing. The fact that the code compiles doesn't always guarantee that it will run.

    Again, as Shane suggested, you need to tell us more about what you're trying to do.
    Charlotte

  4. #4
    2 Star Lounger
    Join Date
    Dec 2000
    Posts
    119
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Debugging strategy (A2K)

    Well, the failure isn't in line, it just "doesn't work".

    Here's the scenario:

    - FormA has some controls that are read to dynamically create an SQL statement.
    - FormA passes the SQL through an ADO connection to create a recordset.
    - FormA equates the recordset to subFormA in datasheet view and visiblizes subFormA which displays only identifying fields
    - User selects a record on subFormA and clicks 'Edit'
    - FormA cmdEdit_Click opens FormB and loads it with the full contingent of fields. (FormA stays open and visible.)
    - User can either edit and 'Save' on FormB (this part works) or click 'Delete' on FormB.
    - FormB cmdDelete_Click sets a public flag blnDelRec in FormA and closes FormB.
    - FormA Activate event checks blnDelRec and if True, finds the record that was just displayed and deletes it.

    This process is currently irratic. Sometimes it deletes the record and sometimes it doesn't. However, if I break on the beginning of the FormA 'DeleteRecord' procedure and F8 through it, the record *always* deletes.

    In addition, I am having timing problems because after I delete the record I want to redisplay subFormA reflecting the changes. What is happening is that the requery is getting to the screen before the delete is complete. If I wait a couple seconds and redisplay, the record will be gone.

    So . . . any ideas?
    Thanks,
    Donald

  5. #5
    2 Star Lounger
    Join Date
    Dec 2000
    Posts
    119
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Debugging strategy (A2K)

    See my reply to Shane's message for a full description of the process.

    IMPORTANT NOTE: This thing is entirely local. It is designed as an FE/BE for its ultimate deployment, but I haven't yet moved the BEs off my local drive.

    Thanks,
    Donald

Posting Permissions

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