Heath Stewart wrote: Keep in mind, however, that most databases (Oracle is the only major database I can think of that can hold an array, IIRC) can't hold arrays. So, in Access, MS SQL Server/MSDE, MySQL, etc., this would only be a string. So should it be in your DataSet (well, in most cases). Your caller should be responsibe for serializing and deserializing that string to/from a float[], from a logical perspective. Your right. This is probably a better way to go. Thanks for your insight on this. -- James --

Thanks Russell. That's the ticket. -- James --

Good point - the XML generated is bursting with type information, so there's no reason I can see for this not to work, but it doesn't. How pathetic. Christian I have drunk the cool-aid and found it wan and bitter. - Chris Maunder

So I'm happy to report the problem was with my code and not with the .NET SqlDataAdapter. But I think the circumstances of the problem bear repeating so that others might avoid it. Form A creates some SqlDataAdapters that fill a dataset and periodically refreshes it. At some point, due to user interaction, an instance of "Form B" is created and passed a reference to the SqlDataAdapters. Form B then finds a DataRow in one of the tables of the dataset, does some work on it, and then calls SqlDataAdapter.Update to put the changed DataRow in the database. And this worked _most_ of the time, but occasionally it would not - no data would be updated to the database. It turns out that during Form A's periodic update, it would clear the datatable and the refill it. This process would cause Form B's datarow it was working on to get to a state of DataRowState.Detached. Since the DataRow was now detached, when form B would call SqlDataAdapter.Update, the info from the row would not go to the database because the DataRow is not associated with the DataSet that the adapter was working with. And there was no error to be reported in this circumstance. So the moral of the story is this: Beware what's happening to your DataSet or DataTables while working with a DataRow. And it doesn't hurt to make sure the row hasn't somehow become detatched when you weren't watching. -- James --

So I kept working on it and discovered the following: The NumericUpDown is a contol composed of other controls. If the user pulls up the context menu by right-clicking the TextBox area of the NumericUpDown, the the ContextMenu's SourceControl can be cast to a TextBox, or you can get the parent of the TextBox which will be the NumericUpDown I was originally seeking. If the user right-clicks the spinner portion, the ContextMenu's SourceContol is the NumericUpDown directly. So the code that does what I was asking is here: private void miProg010_Click(object sender, System.EventArgs e) { MenuItem mi = (MenuItem) sender; ContextMenu cm = mi.GetContextMenu(); NumericUpDown nud = null; if (cm.SourceControl.GetType() != typeof(System.Windows.Forms.NumericUpDown)) nud = (NumericUpDown) cm.SourceControl.Parent; else nud = (NumericUpDown) cm.SourceControl; nud.Value = 10; } Hopefully this saves someone out there some grief. -- James --

Mmmm.... I have the same problem, but I haven't faced it yet :-) ( now I'm still fixing bugs)... some ideas... You can set the sorting column in the DataView( so it's supossed that the DataGrid has nothing to do then). Before calling Fill, you can store in some temporary array or struct ( Memory DataTable with Display/Value columns would be fine :) , or maybe you can save it like a TableStyle )the pair values of Column Name / Column Width, and restore it after calling Fill... to avoid ugly things or flickers, it must be possible to say the DataGrid, Hey ! don't draw now... and when all is done... Now you can refresh, but not sure how. Good luck ! Braulio

System.Diagnostics.Process.Start(@"C:\WINDOWS\EXPLORER.EXE /n,/e,C:\"); "Blessed are the peacemakers, for they shall be called sons of God." - Jesus "You must be the change you wish to see in the world." - Mahatma Gandhi

Calling AcceptChanges on the datatable after the Fill did not seem to remove the extra records. However, calling Clear on the table just before calling Fill does the trick. I was a little wary of using Clear for fear of deleting my database, but I see it only clears the table and doesn't mark records for deletion. Thanks for the help! -- James --

Thanks AW and Braulio for the ideas. I'll explore these. -- James --

Thanks Jim Stewart and peenu for the help! :-D I see there are a lot of properties I overlooked. The MaximumSize and MinimumSize properties did the trick: this.MinimumSize = new Size (400,400); this.MaximumSize = new Size (1280,400); -- James --