jackjohnson44
asked on
passing datasets between forms
I have a dataset that is bound to a grid. When you double click on a row in the grid, an edit screen pops up where you can add or edit records. I pass the dataset by reference. If I instead pop up the same screen with an add button, I add a row to the dataset, make my changes, then save. The problem is that if I add a row, even when I get to the add/edit screen, the grid on the main form will show a blank line. It is still bound to the dataset that was passed in (by val, which didn't really work).
The problem is that my "helper" form can add/edit the dataset, but it is affecting the main "browse" form. I don't think that it is a good idea to have forms effect other forms data. How are you supposed to do this? Should I make a copy of the dataset, change that, then merge when I get back to the main page? create a new row, only add to the ds when I save? If I do, what happens when they violate some dataset constraints?
What are my options, and what is the best way to do this? I don't want to have go to the database every time I pop up a screen. I would rather edit the ds that I have, but I dont' want it to effect grids.
The problem is that my "helper" form can add/edit the dataset, but it is affecting the main "browse" form. I don't think that it is a good idea to have forms effect other forms data. How are you supposed to do this? Should I make a copy of the dataset, change that, then merge when I get back to the main page? create a new row, only add to the ds when I save? If I do, what happens when they violate some dataset constraints?
What are my options, and what is the best way to do this? I don't want to have go to the database every time I pop up a screen. I would rather edit the ds that I have, but I dont' want it to effect grids.
Windows or web?
if it is a web app :
then before redirect the page, store the dataset into a session and get the session value on to the next page. In page1.aspx:
Session("storedata") = datasetobject
response.redirect("page2.a
in page2.aspx form_load
datagrid1.datasource=Sessi
or
dim ds as dataset = Session("storedata")
==========================
if it is a windows app :
create a module called module1.vb
declare:
Public ds as dataset
then in the first from
ds=yourcurrentdataset
in the second form
datagrid.datasource=ds
then before redirect the page, store the dataset into a session and get the session value on to the next page. In page1.aspx:
Session("storedata") = datasetobject
response.redirect("page2.a
in page2.aspx form_load
datagrid1.datasource=Sessi
or
dim ds as dataset = Session("storedata")
==========================
if it is a windows app :
create a module called module1.vb
declare:
Public ds as dataset
then in the first from
ds=yourcurrentdataset
in the second form
datagrid.datasource=ds
ASKER
windows
try passing
DataSet.Copy();
and then merging the two datasets' after the opertion..
DataSet.Copy();
and then merging the two datasets' after the opertion..
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
thanks for taking a look at this. I really don't have a preference as to how the datasets are shared/passed, I would like to know what is considered best before I try to try new things. I am using a guid for a primary key and create on in the form and set the cell to that. I understand your approach to filtering on a null value, but because it is strongly typed, I have to put that in there. How would you suggest filtering the records to not show new rows, only updates?
Another thing to consider:
Also, if I try allow the browse grid on the main form to be editable/add row enabled too, as soon as I started typing in a column, my criteria for filter would probably not be met and it would disappear from the grid.
Another thing to consider:
Also, if I try allow the browse grid on the main form to be editable/add row enabled too, as soon as I started typing in a column, my criteria for filter would probably not be met and it would disappear from the grid.
Try this demo. A form with one datagridview - called dgv - and this code
Public Class Form1
Private dt As New DataTable("TestTable")
Private dv As New DataView
Private Sub filltable()
Dim dc As New DataColumn("ID", GetType(Integer))
dc.AutoIncrement = True
dt.Columns.Add(dc)
Dim dc1 As New DataColumn("Name", GetType(String))
dt.Columns.Add(dc1)
For i As Integer = 1 To 10
Dim dr As DataRow = dt.NewRow
dr(1) = "Name" & i.ToString
dt.Rows.Add(dr)
Next
dt.AcceptChanges()
End Sub
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
filltable()
dv.Table = dt
dv.RowStateFilter = DataViewRowState.Unchanged
dgv1.DataSource = dv
End Sub
End Class
The first sub is just to provide dummy data on which to work. It is the stuff in the form load sub that might interest you.
The .AllowUserToAddRows property is left as True. So it is possible to enter a new row but, when and only when that new record is "committed" to the datatable - e.g. by the user clicking on a different row - it disappears from the grid. That is, the dataview's filter only operates on "committed" records. I would have thought, though, that that was unlikely to be a real problem. If your users are supposed to enter new records on a different form, I would have thought it sensible to set .AllowUserToAddRows to false on your "browsing" grid.
Roger
Public Class Form1
Private dt As New DataTable("TestTable")
Private dv As New DataView
Private Sub filltable()
Dim dc As New DataColumn("ID", GetType(Integer))
dc.AutoIncrement = True
dt.Columns.Add(dc)
Dim dc1 As New DataColumn("Name", GetType(String))
dt.Columns.Add(dc1)
For i As Integer = 1 To 10
Dim dr As DataRow = dt.NewRow
dr(1) = "Name" & i.ToString
dt.Rows.Add(dr)
Next
dt.AcceptChanges()
End Sub
Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
filltable()
dv.Table = dt
dv.RowStateFilter = DataViewRowState.Unchanged
dgv1.DataSource = dv
End Sub
End Class
The first sub is just to provide dummy data on which to work. It is the stuff in the form load sub that might interest you.
The .AllowUserToAddRows property is left as True. So it is possible to enter a new row but, when and only when that new record is "committed" to the datatable - e.g. by the user clicking on a different row - it disappears from the grid. That is, the dataview's filter only operates on "committed" records. I would have thought, though, that that was unlikely to be a real problem. If your users are supposed to enter new records on a different form, I would have thought it sensible to set .AllowUserToAddRows to false on your "browsing" grid.
Roger
ASKER
thanks Roger,
I will try that.
My browse grid did not allow users to add rows. When I popped up my add/edit screen, I either had a either bound to the row being edited via a currency manager, or added a new row to the dataset and bound to it. When I add this row, the screen in the background, the browse screen, will display the blank row as soon as my add/edit screen adds the row. That is pretty much the only behavior that I want to get rid of. I would like to have to "accept" in some way on the add/edit screen before any other screens see this new, or edited data. Also, if someone edits a name for instance, and the add/edit screen crashes, the browse screen could show data that was never verified or really saved.
I will try that.
My browse grid did not allow users to add rows. When I popped up my add/edit screen, I either had a either bound to the row being edited via a currency manager, or added a new row to the dataset and bound to it. When I add this row, the screen in the background, the browse screen, will display the blank row as soon as my add/edit screen adds the row. That is pretty much the only behavior that I want to get rid of. I would like to have to "accept" in some way on the add/edit screen before any other screens see this new, or edited data. Also, if someone edits a name for instance, and the add/edit screen crashes, the browse screen could show data that was never verified or really saved.