G
Guest
Let me run through the first problem I had with a master-detail setup on two Windows datagrids, as it may relate to the second problem
I have two datagrids set up for master-detail as recommended by Microsoft. That is, something like this
dataGridMaster.SetDataBinding( dataset, dataset.masterTable.TableName )
dataGridDetail.SetDataBinding( dataset, dataset.masterTable.TableName + ".actualrelationname" )
The first problem I had was if the user edits a [non-key] value in one of the detail rows and then clicks on a master row OTHER THAN the master for the detail he just edited, the edited value is applied to the newly-selected master's detail row, rather than to the detail row that was actually edited. Hopefully someone can follow that statement
Let's use the customer-order example. Say I have customers A and B. I have clicked on customer A in the master grid and am thus displaying orders A-1 and A-2 in the details grid. I edit order A-1 and, say, change the shipping method from FedEx to UPS. Then I click on customer B in the master grid. The problem is that the new shipping method UPS is applied to order B-1 because I clicked on customer B
I stripped my code to the barest essentials (basically just doing the SetDataBinding calls on the grids) and always had this problem. My workaround was to force an EndEdit on the current details cell any time I left the datagrid or the form closed. Fine, fixed the problem
That being said, the second problem I cannot find a workaround for is this
I have entirely new customers and orders in my tables, which received negatively-incrementing autogenerated primary keys. When saved to the database, a stored procedure returns the new SQL Server-generated keys and everything's fine. The customer-order relation has cascading updates and so, when the customers table is saved, the new keys cascade down to the orders, and then the orders are saved and everybody's happy
HOWEVER
Any order that has been edited in the details datagrid (and ONLY THOSE that have been edited in the datagrid) prior to saving somehow breaks the cascading updates, ONLY for rows that have been edited in the datagrid. So when the new customers get their new SQL primary keys via the stored procedure, the new keys don't cascade to the orders and then SQL Server rightly throws a foreign key violation since we're now trying to save orders that still have the local negative keys
I can edit new customers and orders via other non-datagrid methods and have no problems whatsoever
At a minimum all I'm looking for is confirmation that this is a framework bug and I'm not crazy. At best, a workaround or patch is what I seek
Thanks to all for reading this and any suggestions you may have.
I have two datagrids set up for master-detail as recommended by Microsoft. That is, something like this
dataGridMaster.SetDataBinding( dataset, dataset.masterTable.TableName )
dataGridDetail.SetDataBinding( dataset, dataset.masterTable.TableName + ".actualrelationname" )
The first problem I had was if the user edits a [non-key] value in one of the detail rows and then clicks on a master row OTHER THAN the master for the detail he just edited, the edited value is applied to the newly-selected master's detail row, rather than to the detail row that was actually edited. Hopefully someone can follow that statement
Let's use the customer-order example. Say I have customers A and B. I have clicked on customer A in the master grid and am thus displaying orders A-1 and A-2 in the details grid. I edit order A-1 and, say, change the shipping method from FedEx to UPS. Then I click on customer B in the master grid. The problem is that the new shipping method UPS is applied to order B-1 because I clicked on customer B
I stripped my code to the barest essentials (basically just doing the SetDataBinding calls on the grids) and always had this problem. My workaround was to force an EndEdit on the current details cell any time I left the datagrid or the form closed. Fine, fixed the problem
That being said, the second problem I cannot find a workaround for is this
I have entirely new customers and orders in my tables, which received negatively-incrementing autogenerated primary keys. When saved to the database, a stored procedure returns the new SQL Server-generated keys and everything's fine. The customer-order relation has cascading updates and so, when the customers table is saved, the new keys cascade down to the orders, and then the orders are saved and everybody's happy
HOWEVER
Any order that has been edited in the details datagrid (and ONLY THOSE that have been edited in the datagrid) prior to saving somehow breaks the cascading updates, ONLY for rows that have been edited in the datagrid. So when the new customers get their new SQL primary keys via the stored procedure, the new keys don't cascade to the orders and then SQL Server rightly throws a foreign key violation since we're now trying to save orders that still have the local negative keys
I can edit new customers and orders via other non-datagrid methods and have no problems whatsoever
At a minimum all I'm looking for is confirmation that this is a framework bug and I'm not crazy. At best, a workaround or patch is what I seek
Thanks to all for reading this and any suggestions you may have.