multiple datagrids - how to interact between them? 3

[schick]

I'm a ASP.NET Newbie.
I've got 4 tables. (Groups, Roles,Company,User)
They are connected via Primary keys & Foreign keys.
Want to create a single .net page that allows the user to:
Add/Edit/Delete a company,user,role

what I've got so far is 3 datagrids.

Starts off viewing a company, you click on a button in any row and the "users" for that company are displayed in a second datagrid. This "users" datagrid contains buttons in each row that take you to a "roles" datagrid where a role can be added to that user.

Am I going about this the right way?

 

[jzelhart]

I have done something similar. I needed to Hide the first grid when the other grid was showing. I later did this theory with nexted datagrids - the code is more difficult but very clean on the screen.

Always more than one way to do everything but this is a good starting point.

Just my two cents.

Hope everyone is having a great day!

Thanks - Jennifer

 

[BoulderBum]

Another option is to have different pages for each grid you want to create. It would arguably be more manageable, though it potentially requires more code.

 

[Isadore]

Jenn/BB: Is multiple DataGrids the best approach for Editing/Updating Master/Detail forms? For displaying data I would bind relational tables within a DataSet to the DataGrid but for editing/updating Master/Detail is there not a better way to carry this out? I'm not offering a solution, as I have not had to address this problem, but my general feeling is there must be a better way to do this, perhaps not.

For example, for one to "delete" a primary field in the principal table would require the cascade deletion of related rows in related tables, a process not so amenable to DataGrid function. I guess so long as the editing/updating are removed from the primary and foreign keys there'd generally be no problem.

It may be that DataGrids are the best approach for editing/updating Master/Detail forms but it strikes me that although it can be done this way, it perhaps is not the best approach.

 

[BoulderBum]

I think that, in general, the DataGrid is the best way to display and manipulate a collection of data where bulk Updates and Deletions may be needed (assuming you require a web interface). I think it is best done through the grid's DataKeys collection and a DataAdapter with the UpdateCommand, DeleteCommand, etc. set.

As far as worrying about referential integrity after Deletion/Updates, I think this is a problem you'll face no matter which control you use (you'd need to find a solution in the data layer).

Of course, SQL Server can be rigged to cascade updates and deletions automatically, or you may explicitly declare SQL to handle cascades in the sproc you use for the Update/DeleteCommand of the DataAdapter.

 

[jzelhart]

I agree that the datagrid is the best way to do this. The only problem I see with the query is that the primary would be repeated multiple times which can be confusing for the end user. They might not understand that if you make a change in one that it would change all of the primary fields. You may be able to hide duplicates like you do in reports but I have never tried to do this.

I use the Referential Integrity to deal with the Cascades but I would probably code it to do the updates and deletes as well.

Hope everyone is having a great day!

Thanks - Jennifer

 

[Isadore]

Jenn/BB: One more tidbit, and Boulder, you may have been referring to this when you referenced the dataadapter. I understand that the display of data in multiple datagrids may be the best solution, but would it not be best to create a DataSet with all the required tables, create your relations collection, , etc... and then maintain the update/edit/delete operations within the DataSet (binding the Grid to tables in the DataSet) until the final updating is needed - keeping it down to one operation at the end.

The DataSet is a very powerful feature of ADO.NET as you well know, and seems that when working with Master/Detail problems it might be the best way to go - i.e., instead of using the Itemevents of the DataGrid one can just maintain the updating of the DataSet until a DataAdapter is used to update the database on the server. Of course, the DataSet can be maintained within the client's memory (another big advantage?).

So, final thought, DataSet v. ItemCommand in DataGrid?

 

[jzelhart]

Isadore,

How do you create the display of the records without the master records showing multiple times? For Example:

MasterID MasterRef ChildID Child Ref
1 One 100 One child 100
1 One 200 One child 200
1 One 300 One child 300
2 Two 400 Two child 400
2 Two 500 Two child 500
etc...

I wouldn't want the client to see the repeats or 1 One and 2 Two.

Hope everyone is having a great day!

Thanks - Jennifer

 

[Isadore]

Jen: Well, I guess the jest of what I was trying to argue is that you could show the individual results on detail grids, but by-pass the DataGrid's Update Command and maintain the various editing, adding and deleting operations within a DataSet -- then, when the user is finally done, use a DataAdapter to update all the records -- sure, you'd only want to show one record each and minimize any confusion there (not showing the parent data over again; I agree). I guess what I'm asking is it better to utilize the update/add/delete command events of the Grid itself or alternatively maintain a DataSet in the background and submit all the changes at once. Which would be the best approach? I suppose it depends, e.g., whether maintaining a client side cache object (DataSet) is feasible, etc... Just a thought -- suppose I could work up an example and post back.

 

[BoulderBum]

I think the DataSet idea is a great one, and I would concur that for bulk updates using a DataSet with a DataAdapter may be the most elegant and simple approach. I would note, however, that I don't think the DataSet/DataGrid are mutually exclusive.

In a page of mine, I have a DataGrid with a CheckBox in one column, and on PostBack I get all the rows with a checked CheckBox, add them to a DataSet, and call the DataAdapter.Update() function to process record insertion.

You can also, for example, have the DataGrid's ItemCommand perform an update to a DataSet you've saved in Session or something (instead of a direct call to a SqlCommand), then have a "Save Changes" button that uses the DataSet and a DataAdapter to persist the updates.

In short, I'm with you on the DataSet thing, but I can't think of a better interface to make changes to the DataSet than through a DataGrid.

'My two cents.

 

[jzelhart]

I think that we are all in agreement.

When I am working with the datagrid, I don't leave the dataset open so all of the Updates Add and Deletes are done in a ExecuteNonQuery.

But as with most things in .Net there is always more than one way to do things and one is not always better than the other.

'My two cents as well.

Hope everyone is having a great day!

Thanks - Jennifer