none
Debugging VB program in Visual Studio 2010 RRS feed

  • Question

  • I have an intermittent bug in a VB program which accesses data from an Access Database. I have tried to narrow down this elusive bug but am not sure how to do this in a systematic fashion. Can I trace the steps in my program until the bug shows up and would this help. if so how do I set up Visual studio to Trace each step as it is executed until the bug is encountered.

    Thanks for any help

    Phokaeas

    Thursday, November 9, 2017 8:22 PM

Answers

All replies

  • If "trace" means what I think it does then the first response is the likely answer but there might be other possibilities.

    If "until the bug shows up" means you can write an "if" statement to check if the problem has occurred then there are many possibilities. You could conditionally write debugging output (such as using Console.WriteLine). You could then put a breakpoint on the Console.WriteLine to stop execution when the problem occurs so you can look at what is happening.



    Sam Hobbs
    SimpleSamples.Info

    Thursday, November 9, 2017 9:43 PM
  • Phokaes,

    In the context of Visual Studio are debugging and tracing two complete different thinga. Tracing means that you write constantly data which tells what your program did. 

    Debugging means that you can run your program to a certain point and then step through it. 

    Debugging with Visual studio 2010 is easy. Position your mouse on a certain line and right click on that. Now choose set breakpoint or conditional breakpoint. 

    Then click start and your program stops at that line as it comes there. With the F10 and F11 key you can now step through your code. 

    Be aware for those using Visual Studio 2017, they have removed this in that version. (You can do but not so easy. They have removed the debug functionality from the context menu). Which somebody has written you can set that back yourself, but there is nowhere complete written how beside that it is easy.


    Success
    Cor



    • Edited by Cor Ligthert Thursday, November 9, 2017 10:53 PM
    Thursday, November 9, 2017 10:50 PM
  • In the context of Visual Studio are debugging and tracing two complete different thinga.

    What you say is close enough. I think the important thing is that in the context of Visual Studio the term "trace" is not clearly defined. I would say that the debugger can be used to do a trace but I won't say any more about that; it is not relevant here except I think it would help for Phokaeas to define what is meant.

    There are even Windows API functions ("OutputDebugString" in particular) that is considered a Windows debugging function that could be considered to be useful for "tracing". Another Windows API debugging function is DebugBreak. The Windows API debugging functions are usually not useful but it depends on the requirements.



    Sam Hobbs
    SimpleSamples.Info

    Thursday, November 9, 2017 11:20 PM
  • What I mean by trace is: in the process of running the application in the debug mode, I want to know specifically where the bug was encountered; for example, a line number of the code, the class in which it was encountered and finally what the error was. Getting all or some of this information would help. Right now I sense there should be a way to do this, but I don't know how to do it.

    I hope this clarifies my issue

    Thanks

    Phokaeas



    • Edited by Phokaeas Friday, November 10, 2017 5:20 PM
    Friday, November 10, 2017 5:19 PM
  • I think we need more information about "the bug". The solution probably depends on the known details of the bug.


    Sam Hobbs
    SimpleSamples.Info

    Friday, November 10, 2017 6:12 PM
  • Running in Debug mode or release mode makes no difference while tracing. 

    If you catch an error you can write a message in a trace file. Which needs something extra. 

    https://docs.microsoft.com/en-us/dotnet/visual-basic/developing-apps/programming/log-info/how-to-log-exceptions


    Success
    Cor

    • Marked as answer by Phokaeas Saturday, November 11, 2017 4:56 PM
    Friday, November 10, 2017 6:20 PM
  • I want to know specifically where the bug was encountered; for example, a line number of the code, the class in which it was encountered and finally what the error was.

    That will depend on the nature of the bug.  For instance, an error is quite different than a bug - I presume you really do mean a bug and not an error, because an error will always have a message that tells you the problem and the code where it occurred.  Errors are raised by the runtime system, but you can also raise errors in code.  Presumably you are not talking about that sort of problem.

    Tracing is one way of finding a bug, but there are many others.  And there are different ways to trace.  For instance, you can trace the flow of the logic in the program, you can trace the value of a variable as it changes or you can trace the lifetime of an object.   VS supports most types of debugging procedures, but you can always do your own, such as writing to a message window or writing to a log file.  You just have to decide on a procedure that is suitable for the problem that you are trying to track down.  For instance, if the bug is an incorrect calculation, and if that calculation can be verified internally, then a conditional breakpoint is the bet solution. But there are many other possibilities.  You have provided no information about what type of problem you are facing, so any debugging advice is going to be very general.

    • Marked as answer by Phokaeas Saturday, November 11, 2017 4:56 PM
    • Unmarked as answer by Phokaeas Saturday, November 11, 2017 4:59 PM
    Friday, November 10, 2017 8:41 PM
  • Based on your definitions, I would have to say my problem is actually an error. I have Try-catch blocks of code scattered through the application. This error, which appears to be random, occurs when I am doing some operation involving OleDB. The application accesses an Access database in many parts of the application.

    Typical of exceptions I have encountered in Visual Studio, the information provided, at least to me, is next to worthless. The random nature of the error makes me think it is some sort of timing issue because I have been unable to reproduce the error consistently.

    Since this is an OleDB issue I am considering switching to a MySql database server. Any advice?



    • Edited by Phokaeas Saturday, November 11, 2017 5:29 PM
    Saturday, November 11, 2017 5:27 PM
  • I don't understand you, why an Oracle server while SQL Server is as freeware available?

    https://www.microsoft.com/en-us/sql-server/sql-server-downloads


    Success
    Cor

    Saturday, November 11, 2017 5:34 PM
  • Only because I am familiar with using on a separate program written in C#
    Saturday, November 11, 2017 6:23 PM
  • I don't understand you, why an Oracle server while SQL Server is as freeware available?

    https://www.microsoft.com/en-us/sql-server/sql-server-downloads


    Success
    Cor


    I assume you are referring to the express edition since it is the only one that has permanent use as a production database but it has limitations compared to the paid version.


    Sam Hobbs
    SimpleSamples.Info

    Saturday, November 11, 2017 8:44 PM
  • I don't understand you, why an Oracle server while SQL Server is as freeware available?

    https://www.microsoft.com/en-us/sql-server/sql-server-downloads


    Success
    Cor


    I assume you are referring to the express edition since it is the only one that has permanent use as a production database but it has limitations compared to the paid version.


    Sam Hobbs
    SimpleSamples.Info

    Sam,

    Some people have to be paid to get there food. 

    :-)


    Success
    Cor

    Saturday, November 11, 2017 9:56 PM
  • Typical of exceptions I have encountered in Visual Studio, the information provided, at least to me, is next to worthless.

    Perhaps it is not worthless to someone else, although a secret is certainly worthless.

    Saturday, November 11, 2017 10:30 PM