I have a series of rather complex forms that pass data back and forth and I can't quite get them to work right. Every time I nail down one bug it breaks something else. I currently have a button that sets a field on another form the the value of a field on the current form and requeries so the data update displays. It has worked correctly in the past but now I get an "Index or primary key cannot contain a null value" error but I seem to find which field/record/table is the problem child. Does anyone know of an effecient method of determining where the breakdown is?
Advice on bug hunting
- Thread starter Kraj
- Start date
ChrisO
Registered User.
- Local time
- Tomorrow, 00:21
- Joined
- Apr 30, 2003
- Messages
- 3,171
G’day Kraj.
“Does anyone know of an efficient method of determining where the breakdown is?“
No, not really but a few pointers and in no particular order.
One of the things is to know as much as is possible about the situation. All information about an error is important and all information should be taken with a grain of salt.
Another is to not go too far without testing that which is already available. It is a simple thing to say, but testing a small amount of code is easier than testing a large amount of code. Testing small SQL statements is easier than testing large SQL statements. KISS.
If the code or SQL is already large, try to break it down into simple steps. This goes for all failures but requires intimate knowledge of the system to break it down. In all cases that I know…divide and conquer.
Now for the in-built breakpoints and stepping through code... it has never proved advantageous to me. One of the reasons for that is I started with code that did not support breakpoints or stepping. The next thing is that when you start with a new language the effort of learning the new language is better spent on preventing errors not stepping through them. A simple inline MsgBox, not even Debug.Print, still suffices for me.
Finally, don’t give up if the correct outcome appears to elude us, some things take time. Do it in the light of day, sleep on it or even free range think it out while drunk with a knowledgeable friend.
Forty years in another area leads me to this but take it with a grain of salt.
Regards,
Chris.
“Does anyone know of an efficient method of determining where the breakdown is?“
No, not really but a few pointers and in no particular order.
One of the things is to know as much as is possible about the situation. All information about an error is important and all information should be taken with a grain of salt.
Another is to not go too far without testing that which is already available. It is a simple thing to say, but testing a small amount of code is easier than testing a large amount of code. Testing small SQL statements is easier than testing large SQL statements. KISS.
If the code or SQL is already large, try to break it down into simple steps. This goes for all failures but requires intimate knowledge of the system to break it down. In all cases that I know…divide and conquer.
Now for the in-built breakpoints and stepping through code... it has never proved advantageous to me. One of the reasons for that is I started with code that did not support breakpoints or stepping. The next thing is that when you start with a new language the effort of learning the new language is better spent on preventing errors not stepping through them. A simple inline MsgBox, not even Debug.Print, still suffices for me.
Finally, don’t give up if the correct outcome appears to elude us, some things take time. Do it in the light of day, sleep on it or even free range think it out while drunk with a knowledgeable friend.
Forty years in another area leads me to this but take it with a grain of salt.
Regards,
Chris.
Last edited:
What Chris said, plus:
I usually start with debug.Print but if that doesn't clarify things, I walk through the code (type the word Stop somewhere in your code -- then press F8 to move through line-by-line) and use the Locals Windows (to see the value of multiple variables at any one point in time) when I get that "I'm losing control of my mildly complex algorithm" feeling... It forces me to sit back and re-learn the process...
I will also, in a pinch, use a pencil and paper --- away from the computer --- to sketch out things.
Regards,
Tim
I usually start with debug.Print but if that doesn't clarify things, I walk through the code (type the word Stop somewhere in your code -- then press F8 to move through line-by-line) and use the Locals Windows (to see the value of multiple variables at any one point in time) when I get that "I'm losing control of my mildly complex algorithm" feeling... It forces me to sit back and re-learn the process...
I will also, in a pinch, use a pencil and paper --- away from the computer --- to sketch out things.
Regards,
Tim
Similar threads
