[RESOLVED] Visual Studio 2008 Object reference not set to an instance of an object.

[joekerr1347]

Hi, i'm new to database programming and i'm trying to display a specific database item to a textbox but i always get this error Object reference not set to an instance of an object.

this is my code

Public Class Form1
Dim con As New OleDb.OleDbConnection
Dim da As OleDb.OleDbDataAdapter
Dim ds As New DataSet
Dim sql As String

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

con.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\ChicagoBulls.mdb"
sql = "SELECT * FROM Players"
da = New OleDb.OleDbDataAdapter(sql, con)
da.Fill(ds, "Players")


End Sub

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click

txtName.Text = ds.Tables("Players").Rows(0).Item(1) // this is where the error points

End Sub
End Class
i really am running out of idea how to fix this. I will really appreciate any help, Thank you

[vijy]

Check whether the datatable "Players" having rows.
ds.Tables("Players").Rows(0).Item(1)

[techgnome]

a couple things... 1) next time you post code use the [code][/code] or [highlight][/highlight] tags around it. It preserves the indenting and usually makes it easier to read. If you use the highlight tag, you can include the language too [highlight=vb.net][/highlight] or [highlight=sql][/highlight and so on...
2) when you include a comment in the code about where the error happens... try to make it more obvious, highlight it in red, make it bold, what ever, I dang near missed it.


as for the error... it means something in the structure is nothing... on that line, there are 6 possible candidates... some we can rule out.

txtName.Text = ds.Tables("Players").Rows(0).Item(1) // this is where the error points

txtName is on the left, and since it sounds like a textbox, VB would have given you an error before compiling that it didn't exist... Text is a property, so as long as txtName exists, so does Text... two down... 4 more to look at...


Next is "ds" ... which you declared as a New DataSet... so it exists... so that's not likely.... three more.
that leaves TAbles("Players"); TAbles("Players").Rows(0); and TAbles("Players").Rows(0).Item(1)

What you should do is when the error happens, use the debug tools to view the value of each of those parts and see which one is "Nothing" ...
hint: highlight each section (you'll need to select the whole structure, including the ds), and right-click and select "Quick watch" ... If after selecting tables, it isn't Nothing, then you select Rows(0) and it is nothing, then it's because there are no rows (which is what I'm suspecting is the issue).


-tg

[joekerr1347]

Question
You cannot vote on your own post
0
i tried counting the rows and got the same error

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click

If ds.Tables("Players").Rows.Count > 0 Then
txtName.Text = "x"
Else
txtName.Text = "y"
End If

End Sub

does this mean i'm not really connected to my database? is there something wrong with my connectionstring? i'm using access 2007 i already tried saving it to 2000 and 2003 but still got the same error

[joekerr1347]

i'm sorry and thank you for the tip, i will make sure to do it next time. i tried the quick watch and on "Tables", "Players", "Rows" and "Items" it said that those names are not declared. what does it mean?

[techgnome]

you have to select the whole structure... not just the individual words in it.


i jsut noticed something else are you on Windows 7, 64-bit by any chance?

-tg

[joekerr1347]

i already got nothing before the rows. ds.Tables("Players") Nothing System.Data.DataTable and yes i'm using win 7.

[techgnome]

Then that means your table is failing to load.

The reason I asked about Win 7, and your reply about getting nothing before the rows confirms it, is because there is a widely known "feature bug" in Win 7, 64bit... when an exception happens in the Form Load event, the system (IE, Windows) swallows it... unfortuntately it doesn't bother to tell you, so it appears that your form loads w/o issue, which then can cause problems.

Two ways to solve this... move your code out of the Form Load event to somewhere else... not always an option. Good news though is that even though the system is swallowing your exceptions, it's only eating the unhandled ones. So what you'll probably want to do is wrap your code up in a try/catch and display your error in the catch... I think you'll then find that there is an issue with your code.

-tg

[Shaggy Hiker]

As a general rule, you should always wrap database stuff in a Try...Catch block. Whenever you are working with files outside of your application, whether databases, text files, XML, or anything else, there is always a chance that something exceptional will happen. Quite often, there is nothing useful that you can do in that case other than give up, but with a Try...Catch block you at least have the opportunity to give up gracefully. Without the block (everywhere other than the Load event), the exception would just crash the program.

In this case, the most likely issue is that there is something wrong with the connection string. If you wrap that code in a Try...Catch block, and look at the resulting exception, it may be informative...or maybe not, since those DB exceptions can be a bit opaque.

[joekerr1347]

its working now guys. i changed the active solution platform under build > configuration manager from "any cpu" to "x86" ( i'm using win 7 64bit )

[techgnome]

Are you trying to specifically target x86? If you're on 64-bit,why wouldn't you target 64-bit then? Also it probably doesn't really "fix" the issue.

-tg

[Shaggy Hiker]

That doesn't resolve the 64-bit OS issue that TG mentioned. That problem is not related to the target of the program, but is related to the OS that the program runs on. Making it 32-bit doesn't change the fact that an exception in Load would be quietly swallowed. What fixed the problem is that using Jet under AnyCPU will cause it to attempt to find the 64-bit Jet drivers on a 64-bit OS. Since there are no 64-bit Jet drivers, you will get an exception...which is lost in the Load event due to the 64-bit OS feature. By changing the setting to x86, you forced the program to look for the 32-bit Jet drivers, which are the only kind that exist.

So, the change solved the ultimate problem, but only masked the immediate problem. The immediate problem is that any exceptions thrown in your Load event will cause strange behavior, as you have seen, rather than resulting in an exception. You still need to put anything in the Load event handler in a Try....Catch block, and you should put any DB access code in a Try...Catch block.

[techgnome]

AnyCPU will cause it to attempt to find the 64-bit Jet drivers on a 64-bit OS. Since there are no 64-bit Jet drivers

I'm so deeply rooted in SQL Server land, I completely forgot about that.

-tg

[Shaggy Hiker]

I had forgotten, too, until he stated that changing the target solved his problem. There had to be an exception, and it had to be due to his connection string in some way (because the rest is too simple), or his database itself. Changing the CPU target shouldn't have much impact....except for that one essential impact.