SqlProfiler i silnik LocalDb

Podczas pracy z bibliotekami ORM często zastanawiamy się nad tym, jakie zapytania są generowane i wysyłane do silnika bazy danych. Liczymy na to, że gdzieś w bebechach ORM-a następuje solidna optymalizacja i kod SQL jest najwyższej próby:) Mimo to wiele jest przypadków gdy chcielibyśmy obejrzeć kod wygenerowany np. przez Entity Framework.

Analiza zpaytań przesyłanych do silnika SQL to od zawsze zadanie dla SQL Profilera. Nic prostszego zatem niż odpalenie narzędzia, skonfigurowanie połączenia, selekcja zdarzeń, które chcemy śledzić i juz! Gdzie tu problem? Otóż problem pojawi się, gdy zechcemy skorzystać z wbudowanego w Visual Studio silnika SQL LocalDb. Niekoniecznie musimy wybrać go jako docelowy silnik bazy danych naszej aplikacji – podczas kodowania jest to po prostu wygodna alternatywa.

No i tutaj pojawia się zgrzyt, bo nasz poczciwy SQL Profiler po określeniu ścieżki do serwera np. (LocalDb)\MSSQLLocalDB – tak przecież ustawiliśmy sobie ConnectionString w aplikacji – odmawia współpracy.

Możemy sobie jednak z tym w łatwy sposób poradzić – rozwiązaniem jest określenie połączenia z serwerem przez mechanizm połączeniowy Named Pipes. Pewnie kojarzycie ten protokół z okna narzędzia Sql Server Configuration Managera:

0120

Nie zawracaliśmy sobie nigdy nim głowy, bo konfigurujemy głównie protokół TCP/IP. Cóż, teraz przyda się właśnie ów Named Pipes. Musimy jednak dla naszego silnika LocalDb znaleźć właściwą ścieżkę połączeniową dla ww. protokołu. Pomocnym okaże się polecenie sqllocaldb – z parametrem info pokaże wszystkie instancje LocalDb:

012a

a jeśli dodatkowo dodamy nazwę instancji, otrzymamy szczegółowe informacje, w tym potrzebny nam ‚Instance pipe name’:

012b

Wklejamy go więc do SqlProfilera ustawiając Authentication na ‚Windows Authentication’ i możemy się cieszyć podglądaniem LocalDb:) Sposób ten działa zarówno dla wersji SqlProfilera dystrybuowanej z pełnymi wersjami Sql Servera, jak też dla darmowego odpowiednika: SqlExpress Profilera.

Na koniec dodam, że jeśli pracujemy z Entity Framework w wersji 6, jest inny sposób na podejrzenie kodu wysyłanego do bazy danych. Framework otrzymał bowiem funkcję logowania interakcji z bazą danych. By jej użyć wystarczy określić akcję używaną do logowania i przypisać ją np. tak:

appContext.Database.Log = message => Trace.WriteLine(message);

Akcją może być metoda naszego Loggera lub jakakolwiek zdolna przyjąć tekst loga. W powyższym przypadku logowane dane pojawią się w okienku Output.

Jedna lub druga metoda może być bardzo użyteczna – na przykład gdy to my popełniamy błędy w konstruowaniu zapytań i komunikacji z bazą danych. O czym więcej w następnym poście:)

Marcin

Dodaj komentarz