SubmitChanges doesn't save but removes inserts from change set, no errors

Question

I have a deeper question regarding debug functionality of Linq to Sql SubmitChanges() Function.

I want to save a record in a table of a locally cached db (localdbcache: server SqlExpress 2008 client SqlCE). Before calling SubmitChanges I can find the new item via DataContext.GetChangeSet(). After calling Submit Changes, the items to insert have been removed from the ChangeSet. (That's what this function is supposed to do.) There are no Changes Conflicts and no error in the db's log output. No Exception at all. The table's Count stays at the same value.

if ((e.Parameter == null) ||
   (!e.Parameter.GetType().Equals(typeof(LibDB.Client.Vehicles))))
{
    return;
}

LibDB.Client.Vehicles tmp = e.Parameter as LibDB.Client.Vehicles;

try
{
    ChangeSet cs = this._dc.GetChangeSet();

    if ((tmp == null) || (this._dc == null)) return;

    if (this._dc.Vehicles.Where(veh => veh.Vin == tmp.Vin).Count() == 0)
        this._dc.Vehicles.InsertOnSubmit(tmp);
    else if (this._dc.Vehicles.Where(veh => veh.Vin == tmp.Vin).Count() == 1)
        this._dc.Vehicles.Attach(tmp, true);
    else
        return;

    using (TransactionScope ts = new TransactionScope())
    {
        try
        {                        
            this._dc.SubmitChanges();
            //this._dc.Refresh(RefreshMode.OverwriteCurrentValues,
            //    this._dc.Vehicles);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }

    if (this._dc.Vehicles.Where(veh => veh.Vin == tmp.Vin).Count() == 1)
        MessageBox.Show("Vehicle not saved.");

    this.vehSelector.ResetLayout();
}

I would appreciate any help since I'm loosing hope to find any error, Thanks in Advance Winston

Answer 1

Does your entity have a primary key defined in the db?

Answer 2

Check the count on a new instance of _dc. You're supposed to dispose it after calling .SaveChanges()

Another way to isolate the problem, is to take a look at the count on the table itself, without using Linq.