I recommended in my first post to simplify the code. Get simpler code
working. Judicious use of commenting out code, and/or copy-n-paste, or
real
time debugging. Useful skills that work for me always.
That's fine for you, but if someone isn't sure of what the code is that they
are commenting out, then it's nothing more that a spin of the roulette
wheel. It's not very educationally sound advice.
Create a connection in separate code, and get that working. Then add the
existing code till it breaks, and pinpoint the problem. 20 minutes, tops.
He didn't follow my advice.
Maybe he didn't know how to get a working connection? Maybe that is the
problem? Again, not very educational.
He didn't learn anything from you, other than "when a problem arises, give
up, and post to the newsgroups"
Really? Have you no understanding of how to read:
"If you aren't using a password, then you should remove the Password= part
of
the connection string.
If you do need a password, then you have forgotten to add it here
If your INSERT command is incorrect, you will get an error as well
You should ALWAYS put your connection.Open inside of a try...end try
Why are you renaming the exception that is caught in the Catch to err? This
is a reserved word that represents the VB 6.0 error object. It is a good
idea to leave the name at ex.
Why not use the Catch for the purpose it was intented? Right now, you are
taking any exceptions you get and just throwing them again. I know that for
production purposes that may be what you want to do, but in development, you
can use the catch to find out what is going wrong."
These are all solid points that have an explanation attached to them.
Please Jeff, now you are just slinging mud so you won't have to admit that
you weren't really helping at all.
He'll be back. Yes, I take concern on that. Others don't. Not a problem.
Just my thing.
Listen to yourself. Are you on some sort of crusade? You really don't have
any understanding of how learning takes place do you?
You made 9 posts and in not one of them did you discuss the actual problem
or possible problems. You repeatedly told the OP to do things he obviously
didn't know how to do and were not very nice about it in the process. You
want someone to blame for the OP having to come back 8 extra times? Go look
in the mirror.
Yes, he may be back, but probably with a different problem. And, when that
happens, helpful people like me and most others here will supply the
information that the OP's need. That's kinda how this whole NG thing works.
If you don't like that, then you really are in for some disappointment and
stress.
And I'm a professional trainer too, 10 years at Microsoft, 2 years
teaching
MCP classes at a large university in Seattle, and authored a book on IIS.
No wonder I've never heard of you though, you aren't a very good one.
You've clearly shown here that you don't have any understanding of how the
learning process works. You've shown that, while you may have good
technical skills, you don't posses the necessary patience and imagination to
teach adults new concepts. It's one thing to know something, it's very
different to teach it.
I'm not an MCT, and for a good reason....The MCT program is very restrictive
about the courseware that must be used and the labs that must be taught.
I've repeatedly found that to teach adults effectively, you can't work with
just one canned solution. You need flexibility and the ability to change
your approach based on the situation. The MCT program doesn't allow for
that.
So you don't encourage your students to learn for themselves? Or learn
proper troubleshooting techniques?
I don't want to argue, I agree that your approach is simply different than
mine.
Jeff, you are VERY GOOD at arguing -- you should do it as a profession. It
is very clear that I gave the OP many suggestions for where to being looking
for problems. In fact, after my one post (as opposed to your 9), the OP
said:
"I guess Scott M is right, sounds like the connection cause the problem.
Testing..."
which tells me that I gave the OP some information to go back and work with.
Randomly, commenting out lines of code (which is what you'll be doing if you
don't understand the lines in the first place) is NOT, nor has it EVER been
a PROPER troublshooting technique. It is a crap shoot. Understanding the
premis behind the code you work with, understanding how to read a StackTrace
(provided by the OP), understanding how the debug process works,
understanding how structured exception handling can not only handle
exceptions but be used as a debugging tool and understanding what "Object
reference not set to an instance of an object." means are all PROPER
troublshooting techniques. It's a good think you didn't write a book on
diagnosing execptions.
Both work.
The reason I give my real email is so we can take inappropriate
discussions
like this offline. I would have sent you this in email, but I don't have
your address. This post of mine offers nothing to the OP or to the group.
Neither have any of your posts. If you kept your posts relevant in the
first place, you wouldn't need to argue with people off line. I'm happy to
have this discussion publicly... Because, I believe I am still teaching
others the PROPER way to test code with my remarks to you and while you may
not be able to absorb what I'm saying, I'm sure others will.
