删除行-多个表不支持生成的SQL

Question

I am joining tables in my command. I would like to delete the current row.
Below is my command and what I usually do.
But today I have the error:

generated sql is not supported for multiple table delete row

What does that mean??

OleDbCommand mycmdL = new OleDbCommand("SELECT DISTINCT AreaSize.*, Bathrooms.*, Cities.*, Prices.*, Properties.*, Rooms.*, Types.*, Users.* FROM Users INNER JOIN (Types INNER JOIN (Rooms INNER JOIN (Prices INNER JOIN (Cities INNER JOIN (Bathrooms INNER JOIN (AreaSize INNER JOIN Properties ON AreaSize.AreaSizeID = Properties.AreaSize) ON Bathrooms.BathroomID = Properties.Bathrooms) ON Cities.CityID = Properties.City) ON Prices.PriceID = Properties.Price) ON Rooms.RoomID = Properties.Rooms) ON Types.TypeID = Properties.PropertyType) ON Users.UserID = Properties.AgentID WHERE Users.UserID =@userID", clsDataSource.mycon);

myadaptL = new OleDbDataAdapter(mycmdL);
myadaptL.Fill(clsDataSource.myset, "Properties");
tbListing = clsDataSource.myset.Tables["Properties"];

---

Code to delete current row:

try
        {
            if (MessageBox.Show("Are you sure?", "??", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.Yes)
            {
                DataRow myrow = tbListing.Rows[current];
                myrow.Delete();
                OleDbCommandBuilder mybuild = new OleDbCommandBuilder(myadaptL);
                myadaptL.Update(tbListing);

            }
        }
        catch (Exception)
        {

            throw;
        }
    }

Answer 1

But today I have the error:
generated sql is not supported for multiple table delete row

What does that mean??

As the error message says, the DbCommandBuilder can only auto-generate SQL for single table queries. This makes it easy to implement apps maintaining base tables such as Customer, Product, Employee etc. They can be used for something like a Customer-Order-OrderLines-ServiceItem relationship, but you have to go about it differently.

But before you do that know that there are various frameworks out there to help implement and manage this kind of thing for you. Look into ORMs.

---

Since the DataAdapter can only update one table at a time, you will need multiple Adapters. Rather than using a SQL JOIN, you can define the PK-FK relationship. Changes to parent rows will cascade to children.

For demo purposes I have tables cleverly names Parent , Child and SubChild . A parent row can have many child rows (1:m); each child can have many subchild rows (1:m).

// form/class level objects
DataSet dsSample;
OleDbDataAdapter daParent;
OleDbDataAdapter daChild;
OleDbDataAdapter daSubCh;

Elsewhere, configure them:

daParent = new OleDbDataAdapter("SELECT Id, Name, Lorem FROM Parent",
    AceConnStr);
dsSample.Tables.Add("Parent");

var cbP = new OleDbCommandBuilder(daParent);
daParent.UpdateCommand = cbP.GetUpdateCommand();
daParent.InsertCommand = cbP.GetInsertCommand();
daParent.FillSchema(dsSample.Tables["Parent"], SchemaType.Source);
daParent.Fill(dsSample.Tables["Parent"]);


// repeat for Child - use care with copy-paste!
daChild = new OleDbDataAdapter("SELECT Id, ParentId, Name, Lorem FROM Child",
                AceConnStr);
dsSample.Tables.Add("Child");

var cbS = new OleDbCommandBuilder(daChild);
daChild.UpdateCommand = cbS.GetUpdateCommand();
daChild.InsertCommand = cbS.GetInsertCommand();
daChild.FillSchema(dsSample.Tables["Child"], SchemaType.Source);
daChild.Fill(dsSample.Tables["Child"]);

// do the same for the subchild adapter
// omitted for brevity
// ...

// the PK cols
DataColumn colParent = dsSample.Tables["Parent"].Columns["Id"];
DataColumn colChild = dsSample.Tables["Child"].Columns["Id"];


// set FK constraints, rules
ForeignKeyConstraint fkParentChild = new ForeignKeyConstraint("ParentChild",
            colParent, 
            dsSample.Tables["Child"].Columns["ParentId"]);
fkParentChild.DeleteRule = Rule.Cascade;
fkParentChild.UpdateRule = Rule.Cascade;
fkParentChild.AcceptRejectRule = AcceptRejectRule.Cascade;
dsSample.Tables["Child"].Constraints.Add(fkParentChild);


// set FK constraints, rules for Child-SubChild
ForeignKeyConstraint fkChildSub = new ForeignKeyConstraint("ChildSub",
             colChild, 
             dsSample.Tables["SubChild"].Columns["ChildId"]);
fkChildSub.DeleteRule = Rule.Cascade;
fkChildSub.UpdateRule = Rule.Cascade;
fkChildSub.AcceptRejectRule = AcceptRejectRule.Cascade;
dsSample.Tables["SubChild"].Constraints.Add(fkChildSub);

dsSample.EnforceConstraints = true;

When a Parent row is deleted the related child rows will be affected; same for Child-to-SubChild. Note that even if you do not opt for some sort of ORM, lots of this can be broken up and handled by classes related to the actor. For instance, a Room or City class handling that bit of data.

Testing the Relationship(s)

A query for the rows related to "ParentB":

• There are 3 related child rows (3 distinct Child.Ids)
• There are 4 SubChild rows related to those ChildRows
• If you care to decode the names, ChildB1 is the first child row for ParentB; ChildB-1C means the subchild is related to the First childrow related to parentB. That didnt turn out as clear as I thought it would.

Test:

// delete ParentB
var dr = dsSample.Tables["Parent"].Select("name = 'ParentB'")[0];
dr.Delete();

//  if constraints work, there should be
//  multiple Child and SubChild rows affected
var childChanges = dsSample.Tables["Child"].GetChanges(DataRowState.Deleted);
var subChanges = dsSample.Tables["SubChild"].GetChanges(DataRowState.Deleted);

Console.WriteLine("Child changes: {0},  subCh changes: {1}",
                        childChanges.Rows.Count,
                        subChanges.Rows.Count);

Result:

Child changes: 3, subCh changes: 4

Perfect! Deleting a single parent row cascades to also delete the 3 child rows which in turn deletes 4 subchild rows. Take care that there are rows at each level - if there are no related subchild rows, you'll get a NulLReferenceException on subChanges.Rows.Count .

Updating Database

This entails getting the changes and applying them in order. Normally, the DataAdapter applies all inserts, updates and deletes for you at once. That wont work without violating constraints, so use some code to apply the changes in order:

// Assuming changes were applied on DS/DT rows, 
// changed rows should be duly marked, so just
// run the updates

// insert first

DataTable parentRows = dsSample.Tables["Parent"].GetChanges(DataRowState.Added);
DataTable childRows = dsSample.Tables["Child"].GetChanges(DataRowState.Added);
DataTable subChRows = dsSample.Tables["SubChild"].GetChanges(DataRowState.Added);

// dont Update the DS.Tables...it will try
// to do ALL pending changes
if (parentRows != null)
    daParent.Update(parentRows);

if (childRows != null)
    daChild.Update(childRows);

if (subChRows != null)
    daSubCh.Update(subChRows);

// then update..order doesnt matter
parentRows = dsSample.Tables["Parent"].GetChanges(DataRowState.Modified);
childRows = dsSample.Tables["Child"].GetChanges(DataRowState.Modified);
subChRows = dsSample.Tables["SubChild"].GetChanges(DataRowState.Modified);
if (parentRows != null)
    daParent.Update(parentRows);

if (childRows != null)
    daChild.Update(childRows);

if (subChRows != null)
    daSubCh.Update(subChRows);

// then deletes...in reverse order!
parentRows = dsSample.Tables["Parent"].GetChanges(DataRowState.Deleted);
childRows = dsSample.Tables["Child"].GetChanges(DataRowState.Deleted);
subChRows = dsSample.Tables["SubChild"].GetChanges(DataRowState.Deleted);
if (subChRows != null)
    daSubCh.Update(subChRows);

if (childRows != null)
    daChild.Update(childRows);

if (parentRows != null)
    daParent.Update(parentRows);

// our work is done...time for cheesecake
dsSample.AcceptChanges();

Be sure to process deletes in reverse order - subChild first on up to Parent rows. If everything worked as intended, the Access query from before should now be empty:

et voilà !

---

It is not possible to tell from that SQL what you are doing (or if the DB is even modeled correctly). But it is doubtful you would need an adapter for each table - some look like lookups. In that case, they could be helper classes/objects providing that service.

Resources

• MSDN ForeignKeyConstraint Class
• Another way to define parent/child relationship is the MSDN DataRelations Class
• MSDN DBDataAdapter