X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Weird Errors, 2016    
post Dec 2 2018, 06:01 PM

Posts: 45
Joined: 11-June 18

I think I can understand why I'm losing my hair now.
I have been trying to implement a NotInList feature on a database I have been working on. I received error after error and all though I tried troubleshooting it on my own, I got to the point where I thought for my sanity I would post a question on the site.

As I am going through the process and documenting it FINALLY WORKED.
Completely bizarre. Nothing changed other then possibly saving the main database file.

So this leads me to possible troubleshooting steps and what advice do you experienced developers give the newbies when it comes to trouble shooting?

To give you an idea of things that I have done, were:
I have the Option Explicit automatically added;
Of course read and re-read the code checking for spelling mistakes;
Commented out code and then re-added;
Deleted it;
Try using MS's site to troubleshoot the code, double checking syntax, etc.
Tried different versions of code that I found that fit into what I am trying to do

All in all, it leads up to the most frustrating experience...

Any suggestions on first steps that newbies don't know?

Go to the top of the page
post Dec 2 2018, 06:11 PM

Posts: 126
Joined: 25-January 16

You didn't mention setting breakpoint and stepping through code. Also, using the Locals and or Watch windows or Debug.Print.

Run Debug > Compile then Compact & Repair.
This post has been edited by June7: Dec 2 2018, 06:13 PM

To provide db: copy, remove confidential data, run compact & repair, zip w/Windows Compression. Attachment Manager is below Advanced editor window, click Go Advanced below Quick Reply window.
Go to the top of the page
post Dec 2 2018, 08:43 PM

Posts: 45
Joined: 11-June 18

Yeah, only because I didn't find it successful. I went through it but then ended up using the windows help which took me to the website but I still wasn't making any sense of it. I should try looking up some information on how to use those features a little more to be able to use them efficiently.

Go to the top of the page
post Dec 2 2018, 08:54 PM

Posts: 774
Joined: 4-June 18
From: Somerset, UK

Adding breakpoints shouldn't be difficult to understand
Also worth adding debug.Print lines as needed.

Using proper error handling in all procedures is in my opinion essential.
Go to the top of the page
post Dec 3 2018, 07:25 AM

UtterAccess VIP
Posts: 7,752
Joined: 24-May 10
From: Downeast Maine

For more explanation of the techniques mentioned, and maybe some others, this UA Link is fairly old but still very relevant.
Go to the top of the page
post Dec 4 2018, 10:16 PM

Posts: 45
Joined: 11-June 18

Thank you all for the information. The information on the UA site is great. It helps putting pieces together.
I agree the break points and debug.print are useful and essential for good development.
But that comes with experience and every code writing tutorial I've seen starts with 'Hello. World'. I don't believe this enough experience to start diving into the intermediate window and/or debug.print. That information might be in a chapter 2 or 3 but most of the tutorials and information I've seen doesn't provide enough information that I have been looking for.
The simplest of tasks can be a little challenging in a foreign environment and programming is still foreign to me. I have about 20 hours invested into learning VBA in total.

I have spent an easy 2 hours trying to figure out how to use the intermediate window on a NotInList piece of code.
I still don't see how to make it to work other then going to the form, entering foreign text in the list and going through the debug option presented.

But tomorrow is another day and it will be there waiting for me. laugh.gif
Coding is frustrating but it hasn't beaten me yet!

Go to the top of the page
post Dec 5 2018, 07:47 AM

UtterAccess VIP
Posts: 7,752
Joined: 24-May 10
From: Downeast Maine

Debug.Print is useful for a number of tasks, including learning the value that has been assigned to a variable. For instance, if you assign a Where condition for OpenForm:

Dim strWhere As String

strWhere = "LastName = " & Me.cboName

Debug.Print strWhere

DoCmd.OpenForm "MyForm", WhereCondition: = strWhere

OpenForm will fail because LastName is a text field and you do not have text delimiters. The Immediate (not intermediate) window will show strWhere:

LastName = Burns

It may be clear why that doesn't work, so you can adjust strWhere

strWhere = "LastName = '" & Me.cboName & "'"

Now you will see:

LastName = 'Burns'

But it may be more subtle than that. What if LastName is O'Reilly. Now you have:

LastName = 'O'Reilly'

Perhaps you can sort it out, but if not you can post the Debug.Print result in a UA posting. Somebody will spot the problem, and show you how to deal with apostrophes in a last name.

Debug.Print can also be used for any property of a form or a control on that form.

With a break point, you can use the F8 key to step through the code. As you go, you can hover over, say, a variable after the code has advanced to the line after assigning a value to the variable, and the value will be displayed in a little pop-up. Perhaps you are expecting the number 5 to be assigned to an integer variable, but instead it is 0. Right away you know something is wrong, so you can start to explore why 5 was not assigned.

In any case, if you can narrow it down you will go a long way toward solving the code problems.

With either technique, you have to run the code. If it is a command button click event, you need to click the button. If a Form Current event, you need to go to a different record (or open the form). And so forth. If I am building a complicated string to be used as the WhereCondition for OpenForm, I may leave OpenForm out of the code, and use Debug.Print on the string until I am sure it is what I intend. After confirming that the string is being built properly, I will add OpenForm. This saves the bother of opening the form again and again with the incorrect parameters.

Perhaps you picked up on these things from the link, and I am repeating what you have already read. But the point I need to make is that Debug.Print and break points are first tier trouble shooting tools. It is far more advanced to read the code and anticipate the in-progress results than to arrange to have those results displayed.

If you post some code that is giving you headaches (or hair loss smile.gif ), it may be possible to demonstrate in a specific instance how these techniques can be used. Or maybe it is something else, like trying to assign Null to a variable other than one of Variant type. Tutorials tend to use examples, but if those examples do not apply to your situation it can be difficult to translate the techniques into what you are trying to do.
Go to the top of the page

Custom Search

RSSSearch   Top   Lo-Fi    12th December 2018 - 12:10 AM