Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Typed Dataset problem

0 views
Skip to first unread message

Bob

unread,
May 24, 2006, 7:32:54 AM5/24/06
to
Hi,
I have a typed unbound dataset that is passed to a datahandling class to be
filled.
The datahandling class fills it from a sproc using an oledbDataAdapter
(SQLAnywhere database)
The only table in the dataset has two int32 columns.
There is one row of data and as expected, column 0 contains an int and
column 1 contains a null.
I want to update column1.
The following code executes but the row cell remains unchanged.
I cannot see how an assignment statement can execute without error and the
target remain unchanged.
This in itself seems a bug.
I thought it may have been related to there being a null in the field but
the same thing happens when I try to change the value of the column0.
Can anyone see what is wrong?
thanks
Bob
private void button1_Click(object sender, EventArgs e)

{

dsBatchAssignable ds =new dsBatchAssignable();// Typed dataset with two int
fields

if (mDt.GetAssignableBatches(ds))

{

if ((int)ds.Tables[0].Rows[0].ItemArray[0] ==805) //Proving that table has
been filled.

ds.Tables[0].Rows[0].ItemArray[1] = "3"; //inspection shows System.DBNull
value (expected) before AND AFTER assignment.

if (ds.HasChanges())

MessageBox.Show("Altered"); //Dont get here

}

}

Ludwig

unread,
May 24, 2006, 7:40:12 AM5/24/06
to


ds.Tables[0].Rows[0].ItemArray[1] = 3 (without quotes, it's an int)

However, it's strongly typed, why don't you use its generated
properties?
--
Ludwig Stuyck
http://www.coders-lab.be

Nicholas Paldino [.NET/C# MVP]

unread,
May 24, 2006, 8:27:17 AM5/24/06
to
Bob,

This isn't a typed dataset problem. When you return the ItemArray, it
returns a new array, not the array used internally which is holding the
values.

So you end up modifying the value in the array, not the value in the
dataset.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com

"Bob" <b...@nowhere.com> wrote in message
news:OANR6Wyf...@TK2MSFTNGP05.phx.gbl...

Bob

unread,
May 24, 2006, 5:01:50 PM5/24/06
to
Hi, Ludwig and Nicholas,
Thanks for your replies
Firstly, my apologies for the quotes around the three. It was just my latest
grasping at straws attempt.
Nicholas indicates that I am returning the array and therefore modifying a
copy.
I have to disagree with this. The help file indicates that the Itemarray
property gets / sets the row elements. (Used this technique successfully in
VS2003. see below.)
But the main point is that it is a CLR BUG IMHO. (Made a VB project. Same
behaviour.)

An assignment statement should either complete properly or error. There is
no middle ground.

I have proved that the value is unchanged by:
Hovering the mouse over the instruction and expanding the 'inpection'
Querying the value in the immediate window.

The wearying thing is that this used to work in VS2003.
I have a project that was migrated from VS2003 to VS2005 and it still works
so it is not as simple as 'Duh! they broke it.'
Unfortunately there are number of differences between the two projects in
the data retrieval area. so it is hard to infer what is causing this.

But getting it going is not as important as explaining why the assignment
statement is inert. This should be an impossibility.
Bob

"Bob" <b...@nowhere.com> wrote in message
news:OANR6Wyf...@TK2MSFTNGP05.phx.gbl...

Ludwig

unread,
May 24, 2006, 5:13:37 PM5/24/06
to

And what about:

ds.Tables[0].Rows[0][1] = 3;

By the way - and this is not directly related to the original question
- a few days ago I was at a meeting of our user group and Mr Clemens
Vaster did a presentation on WCF. When talking about remoting and
datasets, it came down to the fact that datasets were pure evil.
Would you guys use datasets in some cases?

Bob

unread,
May 24, 2006, 5:42:30 PM5/24/06
to
Hi Ludwig,
Yep, accessing the cell directly works.
Thank you.
So where to from here?
Do we just carry on or do you agree that it is a bug and should be fixed?
(I know, I know, life is too short. But...)
Bob

"Ludwig" <no...@none.com> wrote in message
news:4ri972pjdttpri96u...@4ax.com...

Ludwig

unread,
May 24, 2006, 6:05:47 PM5/24/06
to
On Thu, 25 May 2006 09:42:30 +1200, "Bob" <b...@nowhere.com> wrote:

>Hi Ludwig,
>Yep, accessing the cell directly works.
>Thank you.
>So where to from here?
>Do we just carry on or do you agree that it is a bug and should be fixed?
>(I know, I know, life is too short. But...)
>Bob
>

Well, have a look at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskupdatingexistingrecordsindataset.asp
As you see, Even Microsoft sais that this is te way to do it! And yes,
in MSDN documentation they say: "You can use this property to set or
get values for this row through an array."

But!

I believe that the getter of the property ItemArray returns a copy of
the cell values, not a reference, so you'll get a new array. Changing
that array does not affect the original cell values.

So according to the documentation this seems like a bug.

Bob

unread,
May 24, 2006, 6:15:35 PM5/24/06
to
Hi Ludwig,
Missed your question on datasets,
I tend to normally pass classes that represent the data structure to / from
a data tier.
I only use datasets where I need the advantage of the inbuilt change
handling.
However a certain amount of laziness also creeps in. It's very attractive
to just Fill and Update. In a remoting situation I would find it harder to
justify datasets to myself.
FWIW
regards
bob

"Ludwig" <no...@none.com> wrote in message
news:4ri972pjdttpri96u...@4ax.com...
0 new messages