Wer mit dem Entityframework und Linq to Entities produktiv arbeitet, möchte sich in bestimmten Situationen auch das SQL anschauen, welches aus dem Linq Code generiert wird. Dazu gibt es verschiedene Möglichkeiten:

1. Eine einfache Möglichkeit die SQL Statements zu sehen, ist die Methode ObjectQuery.ToTraceString() http://msdn.microsoft.com/en-us/library/system.data.objects.objectquery.totracestring.aspx.

Leider ist die Methode nur zugänglich, wenn man sich ein ObjectQuery Object anlegt.

        public static List<Customer> GetCustomersPaged( int iPage )
        {
            NorthwindEntities dbCtx = new NorthwindEntities();
            ObjectQuery<Customer> q = (ObjectQuery<Customer>) ( from c in dbCtx.Customers orderby c.CustomerID select c ).Skip( ( iPage - 1 ) * PageSize ).Take( PageSize );
            System.Diagnostics.Trace.WriteLine( q.ToTraceString() );  
            return q.ToList();

            //return ( from c in dbCtx.Customers orderby c.CustomerID select c ).Skip( ( iPage - 1 ) * PageSize ).Take( PageSize ).ToList();  
        }
Man sieht hier den ObjectQuery Code und unten auskommentiert den Code, den ich normalerweise zur Ausführung der Methode genutzt habe.
D.h. es muss der Originalcode verändert werden, um den generiereten SQL Code zu sehen.
2. Eine weitere Möglichkeit, die SQL Statements hinter dem Linq to SQL Code zu sehen, ist der Entity Framework Tracing Provider von Jaroslaw Kowalski.
Der Provider ist unter http://blogs.msdn.com/b/jkowalski/archive/2009/06/11/tracing-and-caching-in-entity-framework-available-on-msdn-code-gallery.aspx beschrieben.
Es gibt dazu auch noch einen Caching Provider, der hier nicht beschrieben werden soll.
Das Besondere am Tracing Provider ist das man keinerlei Codeänderungen vornehmen, muss um die SQL Statements hinter dem Linq Code zu sehen. Hier ein Beispiel, wie Datenzugriffscode mit dem Tracing Provider aussehen könnte.
    public static class DL
    {
        private static NorthwindEntities CreateDbCtx()
        {
#if DEBUG
                EFTracingProviderConfiguration.LogToConsole = true;
                return new ExtendedNorthwindEntities();
#else
                return new NorthwindEntities();
#endif
        }

        public static List<Customer> GetCustomersByName( string customerID )
        {
            NorthwindEntities dbCtx = CreateDbCtx();

            return (from c in dbCtx.Customers where c.CompanyName.StartsWith( customerID ) select c).ToList(); 
        }

        internal static Func<NorthwindEntities, string, IQueryable<Customer>> _CustomersByName =
        CompiledQuery.Compile( ( NorthwindEntities dbCtx, string customerID ) => from c in dbCtx.Customers where c.CustomerID.StartsWith( customerID ) select c );

        public static List<Customer> GetCustomerByNameCompile( string customerID )
        {
            NorthwindEntities dbCtx = CreateDbCtx();

            return _CustomersByName( dbCtx, customerID ).ToList();  
        }
    }
Leider arbeitet der Entity Framework Tracing Provider nur mit der Codegenerierung “Entity Objecte”. Die Codegenerierung “POCO” oder “Self Tracking POCO” kann damit leider nicht verwendet werden.
3. Möglichkeit ist der Einsatz des SQL Profilers, der bei allen SQL Server Datenbanken (grösser als SQL Express) enthalten ist http://msdn.microsoft.com/en-us/library/ms181091.aspx.
Der SQL Server Profiler bietet die Möglichkeit durch Monitoring auf Datenbankebene, die DML Statements zu sehen, die eine Anwendung mit der Datenbank ausführt.
Wenn man noch den Connectionstring der .NET App mit einer Information prepariert, kann man die erhebliche Informationsmenge, die der Profiler sammelt, eingrenzen.
Dazu kann man im Connectionstring ein eindeutigen Applicationnamen angeben.
provider connection string=&quot;Data Source=(local);Application Name=EfTraceApp;Initial Catalog=Northwind;Integrated Security=True;MultipleActiveResultSets=True&quot;"
Nun braucht man die aufgezeichneten SQL Statements im SQL Profiler nur nach dem “Application Name” zu filtern und man sieht nur die SQL Statements der Anwendung.
image 

GunnarD