The first problem here is that you're thinking and talking like a user. That
is, you're being very fuzzy about what exactly your business requirement is,
how you're attempting to achieve the business requirement, and what you're
using to attempt your solution with.
"The controls" is an extremely non-specific description. Even a Form is a
Control. I'm going to go out on a limb here and make an educated guess that
you're apparently data-binding some sort of interface controls to a DataSet.
Furthermore, I can probably safely assume that these are for the most part
some sort of grid controls, but I can't be sure at all. Still, it doesn't
matter that much. The point is that they are bound to a DataSet.
Moving ahead, these Controls are not directly bound to the DataSet.
Depending upon what version of the .Net Framework you're using, you may be
binding the Controls to a set of BindingSource instances, or perhaps to a
set of DataViews, or some other binding medium. They are *not* bound
directly to the DataSet, as a DataSet is just a logical container for a set
of DataTables. But you haven't been specific about that either. And the
devil is in the details.
Now, you're talking about manipulating the DataSet directly, for some
reason. The DataSet is usually a conduit to an underlying Data Source such
as a database, although you didn't say (you did mention a DataAdapter, so
I'll suppose that this is true).
Now, you start off talking about manipulating the DataSet. Somehow. You
aren't specific about that either. You may be doing it entirely
programmatically, or by some combination of the interaction of the user with
the Controls, combined with some manipulation of the DataAdapter(s). Again,
you didn't say. In fact, you didn't mention whether or not you're actually
changing the underlying Data Source or not. A DataSet is a disconnected set
of data that is fetched (copied) from a database (usually). In order to
update the underlying Data Source, you have to use your DataAdapters. How
and when is up to you, but you haven't mentioned anything about that.
Next, you talk about creating a filtered view of the data by cloning the
DataSet, and apparently deleting records from various DataTables in the
cloned DataSet according to some arbitrary "random criteria" (via what
mechanism, you don't say).
At this point, I'm really scratching my head. I can't imagine any business
requirement that would entail deleting records at random. Usually (almost
always) there is some logic to the manipulation, and that logic determines
what records are deleted and what records are not, as well as how. In fact,
you shouldn't be talking about deleting records from the DataSet unless you
plan to delete them in the database as well.
So, at this point, you've stepped off the beaten path and entered the realm
in which you must begin to depend upon your own programming skills to
manipulate the data. In fact, you stepped off the beaten path when you
cloned the first DataSet to filter it. Remember, that DataSet is a proxy for
your underlying Data Store. It is an ambassador, if you will. But now you've
cloned the ambassador, and are working with the clone, who may or may not
(most probably *not*) have any relationship whatsoever with the underlying
Data Store.
Next, you assign the variable you're using ("dataSet11") to the second
DataSet. Note what I've just said here: You didn't assign the *DataSet* to
the second DataSet. Of course, you could not. You assigned the variable, the
reference. Of course the 10 Controls on the form are still referencing the
first DataSet. You haven't done anything *to* the first DataSet. A variable
is simply a handle that is used to access something. All you did was make
the variable reference something else. In essence, where it *was* pointing
to the first DataSet, it is *now* pointing to the second.
When you say that what you want is something like:
dataSet11* = &dsTemp;
- in fact, that is exactly what you got (in a managed sort of way). A
reference type is a managed pointer to an object. So, when you assigned that
"pointer" to the second DataSet, you simply pointed it away from the first
DataSet to point to the second.
But that isn't really what you want to do at all. You've gone way off track,
starting all the way back where I mentioned earlier. So, what we really need
to do is go all the way back to your requirements, *understand how these
tools are designed to be used*, and use them *as they were designed* to
achieve those requirements. Now, what would those requirements be?
I can (again) make some guesses. Let's see how close I can get. You have a
database. You want to create an interface to that database, using ADO.Net
tools and a Windows Forms application. You have a DataSet, which I presume,
is a proxy to the database itself. It is important to note here that the
DataSet is empty until you fill it. What you fill it with is up to you. But
let's assume that for some reason you want to start out with the contents of
10 (?) tables. So, you need to bind those tables to the 10 Controls you
mentioned. But apparently you don't want to display all of the data. So, you
need to filter what is seen and what is not seen. How this is done depends
upon the filter condition you specify. "random criteria" is achievable, but
will require quite a bit of work. Do you have a more specific requirement?
Perhaps, for instance, only 100 records at a time? Ordered in what way? Not
ordered? Filtered by what specific criteria?
Once we determine the answers to these questions, we can determine, based
upon the various capabilities and aspects of the tools, how best to achieve
the goal. But remember, the DataSet you start out with is your connection to
the DataBase. You don't have to look at all of it at once. You don't even
have to fill it all at once. But what you do is going to be based on your
business requirements.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.
"Billy Bob" <no****@devdex.com> wrote in message
news:Od**************@TK2MSFTNGP09.phx.gbl...I have been struggling with this for weeks now. The example the
original person asked isn't QUITE what I'm looking for, but I have a
more likely example. I have run into this a number of times now.
1) Add a dataSet to a form (windows or web) - call it dataSet11.
2) Add a databinding for 10 controls on that form to use the dataset.
3) Fill the dataset (using a SQLDataAdapter for example)
On a windows form at this point, the controls will show all of the data
in that dataset. Using the reference dataSet11 you can manipulate that
dataset. Add rows, remove rows, modify the underlying data etc.
Everything works great.
However, what if at this point you create a filtered view of that data.
So, you add the following.
DataSet dsTemp = dataSet11.Clone();
Now - you delete 80% of the records, and "filter" the data based on any
random criteria.
Now, you want to use that new dataset (dsTemp) on your form. As
expected, if I put:
dataSet11 = dsTemp;
Because it will just point the reference dataset11 to point to the new
dataset.
The problem is that the 10 controls on the form are still pointing /
referencing the original dataset.
What I REALLY want to be able to do (and really feel like I SHOULD be
able to do) is something like the following.
dataSet11* = &dsTemp;
Now - the memory on the heap that dataSet11 is pointing to is adjusted
to point to the new dataset (dsTemp). Automtically (with a call like
the above), ALL of the referneces ("pointer") would automatically be
pointing at the new/filtered DataSet.
Without this (or something like this), you'd have to write a bunch of
code (and it seems like it'd be REALLY inefficient) and iterate over
every control on the form and re-bind it to the new dataset (dsTeemp).
Right? That seems silly to me...
Thoughts?
EJ
ubrinc.biz
*** Sent via Developersdex http://www.developersdex.com ***