none
Debugging DataContext.SubmitChanges

    Întrebare

  •  

    Hello!

     

    I'm diving into the world of Linq to SQL and I'm wondering what debugging practices are recommended for dealing with problems related to SubmitChanges.  Specifically, I'm looking to see if there's an EASY way to see the SQL that gets sent to the SQL server, or to see which entity is causing a particular problem when a SubmitChanges goes bad. Smile

     

    Thanks!

    1 mai 2008 19:35

Răspunsuri

  • Hi Michael,

     

    A practice that has worked for me is starting out with a unit test and setting the Log textwriter of the DataContext class to the console output window, as in

    ctx.Log = Console.Out;

    I'm using the build-in MS Test framework, which means the console output will get written to the test result details window, and you will have all SQL statements there for your inspection.

     

    You might be interested in the query debug visualizer, which let's you see which SQL select statements will fire off right in your code window. Scott Guthrie has written about it here:

    http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx

     

    Finally, when dealing with errors on SubmitChanges you can try to catch the specific exceptions that may occur. An example:

     

    try

    {

    ctx1.SubmitChanges(ConflictMode.ContinueOnConflict);

    }

    catch (ChangeConflictException ex)

    {

    Console.WriteLine(ex.Message);

    foreach (ObjectChangeConflict occ in ctx1.ChangeConflicts)

    {

    Console.WriteLine("Handling concurrency conflict" + occ.ToString());

    occ.Resolve(RefreshMode.OverwriteCurrentValues);

    }

     

    Does this help?

     

    Kind regards,

    Freek

    1 mai 2008 20:14

Toate mesajele

  • Hi Michael,

     

    A practice that has worked for me is starting out with a unit test and setting the Log textwriter of the DataContext class to the console output window, as in

    ctx.Log = Console.Out;

    I'm using the build-in MS Test framework, which means the console output will get written to the test result details window, and you will have all SQL statements there for your inspection.

     

    You might be interested in the query debug visualizer, which let's you see which SQL select statements will fire off right in your code window. Scott Guthrie has written about it here:

    http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx

     

    Finally, when dealing with errors on SubmitChanges you can try to catch the specific exceptions that may occur. An example:

     

    try

    {

    ctx1.SubmitChanges(ConflictMode.ContinueOnConflict);

    }

    catch (ChangeConflictException ex)

    {

    Console.WriteLine(ex.Message);

    foreach (ObjectChangeConflict occ in ctx1.ChangeConflicts)

    {

    Console.WriteLine("Handling concurrency conflict" + occ.ToString());

    occ.Resolve(RefreshMode.OverwriteCurrentValues);

    }

     

    Does this help?

     

    Kind regards,

    Freek

    1 mai 2008 20:14
  •  

    .Log is *precisely* what I was looking for!  Very tasty.  I was looking for a method to set a logger, not expecting it to be a property.  Awesomeness.

     

    As for the the Query Visualizer, that would be awesome if we could use it for inserts. Smile

     

    Thanks!  I have what I was looking for.

     

    As for an aside, I'm pretty disappointed that L2S doesn't include any built-in length-checking validation for columns... bummer.

    1 mai 2008 20:21