I need an approach to storing/editing data amongs forms

13 Mar 2007 8:14 PM

Todd Beaulieu

I'm working on a small, single user .net 2005 windows application in c#
connecting to SQL Express. I'm trying to learn Typed DataSets, DataTables,
DataAdapters, etc. What I need to figure out is a reasonable approach
(doesn't have to be totally academic) to dealing with data. In other words,
how do I store it, display it and manipulate it?

Right now I have created a global DataSet with some TableTables and am
Filling this structure on program startup.

I'm using a freeware custom tree/list control that doesn't seem to support
databinding so I'm loading it up manually from the global DataTable. So far
"ok".

Now I want to be able to add and remove rows and also edit rows.

As an example, say I have a sub form for editing an existing row. Dragging
Columns onto the form creates a BindingSource, a TableAdapter and a DataSet.
I already have two of these in the global structure. Should I be removing
these and trying to bind to them instead in the sub form? Or, do I want to
create local copies for manipulation? But then how would I sync the results
to the global objects? If I do use the global objects, how do I keep the list
in sync with edits, for example?

I guess I'm looking for a "pattern" on housing and connecting to data,
manipulating it throughout the application. I'm hoping to start easy, rather
than jumping into something complicated like MVC.

Thank you for any assistance.

14 Mar 2007 12:44 AM

RobinS

Show quote Hide quote

"Todd Beaulieu" <ToddBeaul***@discussions.microsoft.com> wrote in message
news:91A9715D-4249-4A33-B3B7-B10333358BF0@microsoft.com...
> I'm working on a small, single user .net 2005 windows application in c#
> connecting to SQL Express. I'm trying to learn Typed DataSets,
> DataTables,
> DataAdapters, etc. What I need to figure out is a reasonable approach
> (doesn't have to be totally academic) to dealing with data. In other
> words,
> how do I store it, display it and manipulate it?
>
> Right now I have created a global DataSet with some TableTables and am
> Filling this structure on program startup.
>
> I'm using a freeware custom tree/list control that doesn't seem to
> support
> databinding so I'm loading it up manually from the global DataTable. So
> far
> "ok".
>
> Now I want to be able to add and remove rows and also edit rows.
>
> As an example, say I have a sub form for editing an existing row.
> Dragging
> Columns onto the form creates a BindingSource, a TableAdapter and a
> DataSet.
> I already have two of these in the global structure. Should I be removing
> these and trying to bind to them instead in the sub form? Or, do I want
> to
> create local copies for manipulation? But then how would I sync the
> results
> to the global objects? If I do use the global objects, how do I keep the
> list
> in sync with edits, for example?
>
> I guess I'm looking for a "pattern" on housing and connecting to data,
> manipulating it throughout the application. I'm hoping to start easy,
> rather
> than jumping into something complicated like MVC.
>
> Thank you for any assistance.
>

For data access, you might check out Dave Sceppa's "ADO.Net Core
Reference".

I write all of my applications using the 3-tier approach, separating my UI
from my business layer from my Data Access layer. If you want to know how
to do that, check out Deborah Kurata's "Doing Objects in VB2005" that just
came out. It's a very pragmatic approach, and you end up building an
application, while learning to set up your classes, build your UI, and
write your data access layer.

I don't use strongly typed datasets because they don't give me enough
control. They work okay for fairly straightforward applications, though.

Since your treeview is not bindable, the only choice you have is to reload
that data every time it changes somewhere (and you're going to have to know
that), or every time your form is displayed or gains focus, or whatever.

Too bad it's not bindable.

You could use one (global) dataset for your data to display on multiple
screens, and bind it to a BindingSource. When the data source behind the
BindingSource changes, the BindingSource updates the controls
automatically.

So in theory, if you had a grid on the front screen bound to
myBindingSource, and myBindingSource was bound to myDataSet.Tables(0), and
then you modified an entry in Tables(0) on another screen, it would show
those changes on the front screen, even if you have not persisted them to
the database.

That's my opinion, anyway.

Robin S.