Dlaczego należy jawnie specyfikować czy kolumna ma akceptować wartości puste czy nie?

Home

Załóżmy, że w procedurze składowanej mamy tabelkę tymczasową:

CREATE TABLE #Temp (Column1 Int, Column2 Varchar(15));

Wszystko działa bez zarzutu, może nawet w środowisku produkcyjnym, aż w pewnym momencie ktoś mówi: Wiesz co dzisiaj Twoja procedura wywaliła się i krzyczy, że kolumna Column1 nie pozwala na wartości NULL. Sprawdzasz błąd na swoim środowisku, ale wszystko działa. Sprawdzasz na innym serwerze, na innej bazie danych i też działa. Co u licha?! Magia czy co?

Jak to zwykle bywa w takich sytuacjach nie magia, ale PEBKAC. Jeśli tworzymy tabelkę tymczasową lub inną i nie podamy jawnie czy kolumna ma akceptować wartości NULL czy nie to domyślnie będzie ona... No właśnie tu tkwi problem, a odpowiedź brzmi to zależy.

Przy standardowych ustawieniach będzie akceptować wartości NULL, ale można to zmienić na poziomie bazy danych, a co gorsza na poziomie sesji użytkownika! Wystarczy, więc mała zmiana i nasz kod przestaje działać. Dlatego dobra praktyka mówi więc aby zawsze jawnie specyfikować czy kolumny mają akceptować puste wartości czy nie.

Co do opcji, które sterują tym zachowanie. Na poziomie bazy danych MSSQL służy do tego komenda:

ALTER DATABASE dbname SET ANSI_NULL_DEFAULT [OFF|ON]

Natomiast ustawienia sesji użytkownika określamy w SQL Server Management Studio:

Tools->Options->Query Execution->SQL Server->ANSI

Lub przy pomocy jednej z dwóch komend, które aby było łatwiej mają dokładnie przeciwne znaczenie i się wykluczają:

SET ANSI_NULL_DFLT_ON ON [OFF|ON]
SET ANSI_NULL_DFLT_OFF ON [OFF|ON]

WolframAlpha - ponownie

Home

Rzadko zdarza się aby jakieś narzędzie zaskakiwało mnie tak często i tak przyjemnie jak WolframAlpha (pisałem już o nim tutaj lub tutaj). Po prostu kiedy potrzebuję coś policzyć, sprawdzić i szukam programu lub strony, która to dla mnie zrobi to bardzo często wracam właśnie do WolframAlpha.

Tym razem potrzebował czegoś, co wyznaczy mi linię trendu czyli nic dodać nic ująć tylko tzw. prosta regresja liniowa. Okazało się, że w WolframAlpha służy do tego komenda linear fit. Linia prosta to oczywiście bardzo prosty model, który nie zawsze będzie dobrze działać, ale przy tej okazji odkryłem, że WolframAlpha wspiera również bardziej zaawansowane modele, na przykład komenda cubic fit generuje model w postaci równania trzeciego stopnia. Po więcej przykładów odsyłam do tej strony, zachęcam do zapoznania się i własnych poszukiwań.

A do czego takie modele mogą się przydać? Na przykład do predykcji cen, długości życia w zależności od różnych czynników, liczby odwiedzin strony...

Ja vs Active Directory

Home

Od niedawna mam okazję pracować, przy pomocy API .NET'owego, z usługami katalogowymi w wydaniu Microsoft'u, czyli z Active Directory. Dla mnie nowa rzecz, więc z zapałem dziecka, które dostało nową zabawkę, zabrałem się do pracy i, jak to często bywa w takich sytuacjach, od razu napotkałem problemy właściwe dla początkujących. W ten sposób dowiedziałem się wielu rzeczy, które dla wyjadaczy mogą być oczywiste, ale dla mnie były nowością. Zebrałem więc je do kupy i tak powstała poniższa lista ku pamięci.

Niektóre z tych rzeczy to drobnostki i jeśli o nich zapomnimy nic wielkiego się nie stanie. Niektóre są jednak bardzo ważne i ich pominięcie może sprowadzić na nas większe kłopoty. Tego rodzaju rzeczy oznaczyłem jako [Ważne]

Projektowanie schematu

• [Ważne] Przy projektowaniu schematu AD (definicja klas, atrybutów) trzeba być bardzo ostrożnym. AD nie wspiera usuwania klas lub atrybutów, a wiele rzeczy można zdefiniować tylko przy ich tworzeniu, na przykład atrybuty obowiązkowe dla danej klasy. AD wspiera natomiast tzw. dezaktywację. Ma to podobne skutki jak usunięcie, ale i tak wprowadzanie zmian do już używanego schematu AD może być bardzo kłopotliwe.
• [Ważne] AD to nie C# i nie możesz sobie tak po prostu dodać nowego atrybutu do klasy i oczekiwać, że wszystkie jej instancje zostaną z automatu uaktualnione. Mam tutaj na myśli atrybut mustContain, który określa atrybuty obowiązkowe. Niestety, ale można go podać tylko przy tworzeniu danej klasy. Więcej ograniczeń znajdziecie tutaj.
• Zamiast atrybutu mustContain można jednak użyć atrybutu mayContain, który określa atrybuty potencjalne.
• Pisząc skrypt ldif definiujący nowy atrybut nie wystarczy użyć atrybutu attributeSyntax. Potrzebny jest jeszcze atrybut oMSyntax.

Limit 8KB

• [Ważne] Ponownie AD to nie C#. Obiekty w AD nie mogą mieć więcej niż 8KB, a co za tym idzie, nie mogą zawierać dowolnej liczby atrybutów i wartości. Należy o tym pamiętać szczególnie, jeśli używamy atrybutów wielowartościowych. Ja analizowałem błąd, w którym nie można było dodać nowych wartości do atrybutu właśnie z tego powodu. Przekroczenie limitu 8KB dla danego obiektu skutkuje błędem Administrative limit for this request was exceeded
• Aby było śmieszniej, nie można łatwo wyznaczyć maksymalnej dopuszczalnej liczby wartości, jakie zmieszczą się w danym atrybucie. Zależy to na przykład od tego, ile atrybutów ma dany obiekt. Ten artykuł zawiera fajną dyskusję praktycznych limitów na liczbę wartości w obiekcie. Sekcja Maximum Database Record Size

Atrybuty powiązane

• Pewnym rozwiązaniem problemu ograniczonej wielkości obiektów są tzw. atrybuty powiązane (ang. linked attributes), w których zawartość jednego atrybutu zależy od zawartości innych obiektów. Problemem jest natomiast to, że taki wyliczany atrybut musi być typu distinquished name, a więc nie obsłużymy w ten sposób np.: listy liczb całkowitych.
• [Ważne] Jeśli atrybuty mają być powiązane to muszą być takie od początku.
• Działanie atrybutów powiązanych może nie być intuicyjne, a więc załączam poglądowy schemat. Jak widać atrybuty połączone to para atrybutów tzw. forward link oraz backward link. Backward link przechowuje wskazania na obiekty, które wskazują go w atrybucie forward link.

Stronicowanie

• AD ma ograniczenie na liczbę obiektów, jakie można pobrać z bazy w jednym zapytaniu. .NET pozwala to jednak bardzo łatwo obejść dzięki stronicowaniu. Należy ustawić właściwość DirectorySearcher.SizeLimit na 0, a właściwość DirectorySearcher.PageSize na wartość inną niż 0. Nic więcej nie trzeba robić. Więcej szczegółów tutaj.
• [Ważne] Domyślnie .NET nie używa stronicowania. Jeśli o ty zapomnimy, może dojść do sytuacji, kiedy nasz program nagle przestanie działać, bo nie będzie pobierał wszystkich oczekiwanych obiektów z AD.

Inne

• [Ważne] Klasy z przestrzeni nazw System.DirectoryServices, takie jak DirectorySearcher, DirectoryEntry, SearchResultCollection implementują interfejs IDisposable. Piszę o tym ponieważ nawet przykłady na MSDN nie biorą tego pod uwagę!
• Skrypt ldif, służy do wprowadzania zmian do AD i składa się z sekwencji operacji dodania, usunięcia lub zmodyfikowania czegoś. W przypadku operacji modyfikacji (changetype: add) na końcu powinien znaleźć się znak „-“.
• Uwaga na spacje w atrybucie cn. Mój skrypt ldif dodający do schematu nowy atrybut wywalił się, bo wartość dla atrybutu cn zawierała na końcu spacje.
• AD ma różne limity ograniczające, na przykład maksymalna liczbę wartości, jakie można pobrać, maksymalną wielkość strony itp. Pełną listę można znaleźć tutaj.

Lista ta z pewnością nie jest kompletna. Jeśli macie jakieś sugestie to chętnie ją rozszerzę.

Podsumowania roku są bardzo ważne

Home

Refleksja jak powyżej naszła mnie właśnie podczas takiego spotkania podsumowującego. Niby wiedziałem, jakie projekty były realizowane w czasie zeszłego roku, niby wiedziałem o wszystkich przedsięwzięciach podejmowanych w poszczególnych obszarach (innowacja, zarządzanie wiedzą itd.), zdawałem sobie również ze zmian w zespole... Pomimo tego, kiedy zebraliśmy wszystko do kupy byłem zaskoczony, ale w bardzo przyjemny sposób, i podbudowany jak dużo rzeczy udało się zrealizować.

Niektóre ze zmian były całkiem duże i ewidentnie będą miały pozytywny, długofalowy wpływ. W szczególności mam tutaj na myśli wdrożenie automatycznych testów jednostkowych oraz integracyjnych, wypracowanie zasad ich tworzenia i włączenie ich w oficjalny proces wytwórczy, w czym maczałem swoje palce.

Mniejszych i większych wydarzeń było sporo więcej i ważne, że wszyscy dowiedzieli się lub przypomnieli sobie, co się działo przez ostatni rok, a przecież nie każdy ma ekspozycję na wszystko co się dzieje. Dlatego uważam, że takie spotkania, o ile zrealizowane dobrze, najlepiej wewnątrz zespołu, tak aby skupić się na konkretach bez corporate bullshit, są bardzo potrzebne.

Jeśli w Twojej firmie nie ma zwyczaju organizowania takich spotkań, to wyjdź z taką propozycją albo jeśli masz taką możliwość zorganizuj je samemu.

Brakujące konto MSSQLSERVER

Home

Na swoim lokalnym komputerze pliki baz danych trzymam na innym dysku niż systemowy. Raz, że jest to dysk systemowy i chcę go w razie czego w dowolnym momencie sformatować, a dwa, że jest to dysk SSD i na nadmiar miejsca nie narzekam. Na super wydajności mi natomiast nie zależy. Utworzyłem więc katalog db na innym dysku, bazy przestawiłem w tryb offline, skopiowałem pliki mdf oraz ldf i uaktualniłem ścieżki przy pomocy komendy ALTER DATABASE. Na koniec chciałem przełączyć bazy w tryb online, ale MSSQL krzyknął, że nie ma uprawnień do plików mdf/ldf.

Spojrzałem więc jak skonfigurowany jest domyślny katalog używanego przez MSSQL do przechowywania plików baz danych. Okazało się, że właścicielem jest niejaki MSSQLSERVER. Swój katalog db chciałem więc skonfigurować w ten sam sposób. Głupia sprawa ale wyglądało, że takie konto nie istnieje w systemie! Spojrzałem jeszcze raz na domyślny katalog i wszystko się zgadzało. Przejrzałem listę wszystkich kont i nie znalazłem tam nic przypominającego konto MSSQLSERVER.

Znalezienie rozwiązania zajęło mi trochę czasu i w końcu okazało się, że pełna nazwa konta to NTSERVICE\MSSQLSERVER. Aby było łatwiej jest ono niewidoczne w okienku Select Users or Groups ale jeśli wpiszemy je w pole Enter the object names to select: to zostanie znalezione.