Annoy "Object reference not set to an instance of an object." Help.

[nick]

The code write to a dbf file. However, started from today I always got the
error: "Object reference not set to an instance of an object." And the
StackTrace and code are:

StackTrace " at System.Data.Common.ICommandText.Execute(IntPtr pUnkOuter,
Guid riid, tagDBPARAMS pDBParams, Int32& pcRowsAffected, Object& ppRowset)
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS
dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object&
executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior
behavior, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()
at DAL.Camms.DAL.dalWorkOrder.InsertWO_dbf(Boolean Activity, String
WOTYPE, String REF_NO, String PRIORITY, String Unit, String DEPT, String
DEPT_ID, String PAC2, String RQNAME, String RQPHONE, String SHOP, String
ASTO, DateTime WODATE, String OPTR, String LOCATION, String COMM1, String
ROOM, Double ESTHR, String STATUS, String UP, String FLR) in
C:\DAL\WorkOrder.vb:line 146" String


Class DAL

static public function writedbf()
....
Dim dbfConnectionString as String = "Provider=Microsoft.Jet.OLEDB.4.0; Data
Source=C:\dbfs;Extended Properties=dBase IV;User ID=Admin;Password="

Dim InsertCmdStr As String = "Insert Into wolog (WOTYPE, REF_NO, PRIORITY,
Unit, DEPT, DEPT_ID, PAC2, RQNAME, RQPHONE, SHOP, ASTO, WODATE, OPTR,
LOCATION, COMM1, ESTHR, STATUS, UP, ROOM, FLR) values
('D','D700804','5','90','740','1','2BUS','a','a','SEC','','11/10/2004
2:02:27 PM','login','2 BUS ST a ','a ',0,'N','N','a','')"

Dim cmd As New OleDbCommand(InsertCmdStr, New
OleDbConnection(dbfConnectionString))

cmd.Connection.Open()
Try
REF_NO = cmd.ExecuteScalar()
Catch err As Exception
Throw err
Finally
If Not cmd.Connection Is Nothing Then
cmd.Connection.Close()
End If
End Try

 

[Jeff Dillon]

What is line 146? What have you done to troubleshoot this? Do you have
simpler code working I assume??

Jeff

 

[nick]

Line 146 is

cmd.ExecuteNonQuery()

I didn't do anything, it occurs a couple of time before and then work fine
until today....

 

[Jeff Dillon]

Compare it to simpler working code, and find the differences.

Jeff

 

[Jeff Dillon]

Or, step through the code line-by-line in the debugger, and set watches to
see if/when an object goes out of scope.

Jeff

 

[nick]

The debug stops at cmd.ExecuteNonQuery(), That's trace shows it too:

at System.Data.Common.ICommandText.Execute(IntPtr pUnkOuter, Guid riid,
tagDBPARAMS pDBParams, Int32& pcRowsAffected, Object& ppRowset)
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS
dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior behavior,
Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()
at DAL.Camms.DAL.dalWorkOrder.InsertWO_dbf(Boolean Activity, String
WOTYPE, String REF_NO, String PRIORITY, String Unit, String DEPT, String
DEPT_ID, String PAC2, String RQNAME, String RQPHONE, String SHOP, String
ASTO, DateTime WODATE, String OPTR, String LOCATION, String COMM1, String
ROOM, Double ESTHR, String STATUS, String UP, String FLR)

 

[Jeff Dillon]

Again, compare it to simpler working code!!!

The debug stops at cmd.ExecuteNonQuery(), That's trace shows it too:

at System.Data.Common.ICommandText.Execute(IntPtr pUnkOuter, Guid riid,
tagDBPARAMS pDBParams, Int32& pcRowsAffected, Object& ppRowset)
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS
dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior behavior,
Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteNonQuery()
at DAL.Camms.DAL.dalWorkOrder.InsertWO_dbf(Boolean Activity, String
WOTYPE, String REF_NO, String PRIORITY, String Unit, String DEPT, String
DEPT_ID, String PAC2, String RQNAME, String RQPHONE, String SHOP, String
ASTO, DateTime WODATE, String OPTR, String LOCATION, String COMM1, String
ROOM, Double ESTHR, String STATUS, String UP, String FLR)

 

[nick]

The code is not modified.

Again, compare it to simpler working code!!!

 

[nick]

The is not working code now.

Again, compare it to simpler working code!!!

 

[Jeff Dillon]

Once again, 3rd or 4th time...copy or comment out the code to determine why
it is failing now.

"Use simpler, working code" Do you understand what I mean by this? <----
question that needs an answer upon your next post.

Create a new page, remove all variables, and hard-code similar but
simplified code. This is a traditional (and hard to believe that people
aren't doing this) trouble shooting technique.

Obviously something changed. The most often thing that has changed these
days is XP SP2.

Jeff

 

[Jeff Dillon]

Then find out why. What have you done to find out why, besides posting
here? Simplify UNTIL it works, and compare.

Jeff

 

[nick]

btw, the problem occur when run in ASP.Net application. When run as
non-asp.net application (testing using NUnit), there is no problem.

I already did the impersonate:

web.config:
<configuration>
<system.web>
<identity impersonate="true" userName="yw" password="...." />

Also, I set the Intranet security to high (may not be useful in this case).

 

[Scott M.]

Most likely the problem is that you do not have a valid connection, which
means that you don't have an instance of a connection object, but you don't
know that until you attempt to the use connection which happens when you
attempt ExecuteNonQuery.

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.

I would break up the code to have an explicity connection object like this:

Dim dbfConnectionString as String = "Provider=Microsoft.Jet.OLEDB.4.0; Data
Source=C:\dbfs;Extended Properties=dBase IV;User ID=Admin"

Dim con as New Connection(dbfConnectionString)

Dim InsertCmdStr As String = "Insert Into wolog (WOTYPE, REF_NO, PRIORITY,
Unit, DEPT, DEPT_ID, PAC2, RQNAME, RQPHONE, SHOP, ASTO, WODATE, OPTR,
LOCATION, COMM1, ESTHR, STATUS, UP, ROOM, FLR) values
('D','D700804','5','90','740','1','2BUS','a','a','SEC','','11/10/2004
2:02:27 PM','login','2 BUS ST a ','a ',0,'N','N','a','')"

Dim cmd As New OleDbCommand(InsertCmdStr, con)

Try
con.Open()
REF_NO = cmd.ExecuteScalar()
Catch ex As Exception
'Throw ex
return ex.message 'This will return back the exception message
Finally
'There is no need to check for a connection or an open connection
'Calling close on an already closed connection will not cause an
exception
Con.Close()
End Try

 

[Jeff Dillon]

Ah..."break up the code"...magic to my ears...

there is hope after all.

 

[Jeff Dillon]

Did you simplify the code?? Sounds like you are adding code...to code that
already not working. Hmmm...

Troubleshooting 101

 

[nick]

I didn't add code. The same code (dll file, when called by asp.net it has
the problem). I guess Scott M is right, sounds like the connection cause the
problem. Testing...

 

[Jeff Dillon]

Wow. If you used simpler code, as I suggested, you would have found the
problem hours if not days ago

Jeff

 

[Scott M.]

Interesting Jeff, since I was able to look at the OP and get a feeling for
where the problem was right away.

 

[Jeff Dillon]

Sorry, was I talking to you? My hope that people can learn to solve their
problems themselves.

And feeling? My suggestion would have pinpointed the problem straight away.

Granted, I see 2 schools of thought on newsgroups. One, blindly answer
posted questions. The other, educate.

Mine is to educate. "Give a man a fish, and he'll be hungry by the end of
the day. Teach them to fish, and they will never be hungry again."

Both work. I agree with both. But I choose one style.

Simpler code is always easier to debug and diagnose.

And I give my email in posts, and invite private discourse. Do you?
Granted, I put up with major spam.

Jeff

 

[Scott M.]

Sorry, was I talking to you? My hope that people can learn to solve their

problems themselves.

Then there really is no reason for you to post anything in the first place.
Badgering the OP, when he clearly didn't understand you isn't going to help
anyone.

And feeling? My suggestion would have pinpointed the problem straight
away.

If you consider "straight away" 9 messages from you without getting anywhere
close to the problem vs. one from me, then yes, you are correct.

Granted, I see 2 schools of thought on newsgroups. One, blindly answer
posted questions. The other, educate.

Too bad you did neither. If you read what I wrote, you'd see that I
explained what is most likely the problem and several possibilities as to
why it might be happening. I left it to the OP to go check them out. I
happen to be a professional trainer, so I know a thing or 2 about how to
educate myself. What you did was not helpful to anyone. You were clearly
adversarial and offered nothing that would help the OP to find the problem
much less understand it, so let's just climb down of your soap box for a
moment and be honest here.

Mine is to educate. "Give a man a fish, and he'll be hungry by the end of
the day. Teach them to fish, and they will never be hungry again."

Get real, Jeff. It's quite a stretch to call your continued badgering of
the OP education in any way.

Both work. I agree with both. But I choose one style.

Then perhaps you could do some learning on how to use that style because you
certainly haven't done so here.

Simpler code is always easier to debug and diagnose.

You told the OP to give us simple code that works. The OP couldn't get the
code to work! That was the problem. Perhaps the OP doesn't know what
simpler code there is? Perhaps, that's why we need to help people around
here? No one said you had to write the correct code for the OP, but you
could have been a little kinder and certainly could have been more helpful.

And I give my email in posts, and invite private discourse. Do you?

Why would I need to. Why not let everyone benefit from the problem and the
solution? If you are truly helping someone, then they shouldn't need to
contact you privately to solve their problem.

Granted, I put up with major spam.

And, perhaps the rest of us know that we can avoid spam and help the OP's at
the same time?