SQL Update dst set xyz, from src

Jest to wzór przykładowego update tabeli w t-sql, w oparciu o wyniki innej tabeli, z innej bazy danych. Często go stosuję,  a ciągle zapominam tej składni, więc... postanowiłem to sobie zachować "na przechowanie".


USE [dstInstancja]
GO

UPDATE dst
   SET [zakup] = src.[zakup]
          ,[oplata] = src.[oplata]
 FROM [dbo].[typ_transakcji] dst join [SRVxy\NazwaSerwera].[srcInstancja].[dbo].[typ_transakcji] src
 on dst.Id = src.Id

GO

MS SQL - DEADLOCK

Czasami zdarzy nam się, że procesy pracujące na bazie danych mogą się zakleszczyć. Nie wdając się w szczegóły, chodzi o równoczesne blokowanie jednych zasobów, oczekując na zwolnienie pozostałych. Szerzej to zagadnienie zostało opisane jako problem ucztujących filozofów.

A co, gdy taka syt. zdarzy nam sie na bazie danych?
a) dobrze by było się dowiedzieć, dlaczego dochodzi do zakleszczeń (np. sql profiler)
b) pomyśleć nad zmianą poziomu izolacji tranzakcji
c) wyśledzić odpowiedni proces za pomocą sp_who2 a nast. ubić zawieszony process, odblokowując tym samym zasoby dla innych procesów

exec sp_who2

kill SPID

 

Simple.Data

Simple.Data, to nowy "ORM bez ORM", czyli nowy, mocno uproszczony sposób połączenia aplikacji z bazą danych. Sposób jest bardzo prosty, i pozwala na zaoszczędzenie linii kodu (im mniej tym lepiej), ale kosztem braku sprawdzania poprawności składni podczas kompilacji. Coś za coś. Dla małych, prostych aplikacji, ten ORM może być nawet sensowny, ale w dużych aplikacjach, z rozbudowanymi bazami danych, na których równocześnie pracuje wiele os. zwyczajnie się nie sprawdzi.

Dużo więcej, nt. tego ORM można przeczytać w art. na www.dobreprogramy.pl/. Tam też znajduje się mini tutorial dla tego rozwiązania (więc nie będę się powtarzał).

Rozwiązanie znajduje się na GitHub
Najłatwiej wersje "dla aplikacji" pobrać z NuGet
Dokumentacja z przykładami znajduje się: Simple.Data.Doc

SQL DateTime i DateTime2

Całkiem niedawno, tworząc insert do bazy danych wygenerowanej przez EF spotkałem się z błędem odnośnie parsowania dat z 'datetime2' na 'datetime'. Z tego co zrozumiałem, chodziło o brak inicjacji zmiennej (bo jak wiadomo, .NET Datetime ma domyślą wartość roku 0, a T-SQL Datetime zaczyna się od 1753 roku). Zainicjowanie tej zmiennej na "DateTime.Now();" rozwiązało ten problem, za to, krótkie spojrzenie na forum stackoverflow.com wyjaśnia nam dodatkowe niuanse pomiędzy tymi typami, taki jak np. precyzja dokładności "3 1/3 milliseconds" do "100ns".

Link do do zgłoszenia na stackoverflow

Entity Framework Modified State (updating row values)

Pogłębiając moją wiedzę nt. Entity Framework zauważyłem pewną ciekawą właściwość, mianowicie w syt. gdy tylko niektóre kolumny w wierszu z danymi zostały zaktualizowane, to Entity Framework zachowuje się w różny sposób dla różnego rodzaju aplikacji:
- dla aplikacji okienkowych (windows forms) aktualizuje tylko wybrane kolumny danego rekordu
- dla aplikacji webowych (asp) aktualizuje wszystkie kolumny danego rekordu

In a desktop application, state changes are typically set automatically. In this type of application, you read an entity and make changes to some of its property values. This causes its entity state to automatically be changed to Modified. Then when you call SaveChanges, the Entity Framework generates a SQL UPDATE statement that updates only the actual properties that you changed.
However, in a web application this sequence is interrupted, because the database context instance that reads an entity is disposed after a page is rendered. When the HttpPost Edit action method is called, this is the result of a new request and you have a new instance of the context, so you have to manually set the entity state to Modified. Then when you call SaveChanges, the Entity Framework updates all columns of the database row, because the context has no way to know which properties you changed.
If you want the SQL Update statement to update only the fields that the user actually changed, you can save the original values in some way (such as hidden fields) so that they are available when the HttpPost Edit method is called. Then you can create a Student entity using the original values, call the Attach method with that original version of the entity, update the entity's values to the new values, and then call SaveChanges. For more information, see Add/Attach and Entity States and Local Data on the Entity Framework team blog.

 źródło

T-SQL select po kilku ostatnich znakach

Często zdarza nam się konieczność pisania zapytania typu 'select' po ciągach znaków, typu varchar. Czasami potrzebujemy wyszukiwać lub wyświetlać wyniki tylko po części wyrazu. Wtedy najczęściej wystarczy funkcja SUBSTRING. A co, jeśli potrzebujemy wyszukać część wyrazu po kilku ost. znakach (np. dane, które posiadamy są różnej długości*)?? Wtedy z pomocą przychodzi nam funkcja RIGHT

SELECT RIGHT(column, 3)

* - przykład 'życiowy'. Dane, które przychodzą z jednego, z zewnętrznych syst. informatycznych, z którym się integrujemy czasami przychodzą w formacie '0000xxx' (np. 0000123), a innym razem jako 'xxx' (np. '123').

Obrona przed XTML Injection, XSS (Cross-Site Scripting) poprzez Strip

Jednym z najpoważniejszych zagrożeń związanych z bezpieczeństwem aplikacji internetowych jest HTML Injection, czyli jedna z odmian Code Injection. Problem bezpieczeństwa związany HTML Injection polega głównie na Cross-Site Script, czyli wstrzyknięciu na stronę www kodu HTML zawierającego wykonujące się skrypty (np. w języku 'Javascript'), które mogą służyć m.in. do zmiany ustawień konta, wyciągania wrażliwych danych od użytkownika i innych niepożądanych czynności.
Kod HTML zawierający szkodliwe skrypty można wstrzyknąć np. do textBoxów pobierających od użytkownika dane.

W jaki sposób się przed tym bronić? Jednym ze skutecznych sposobów ochrony przed tego typu nieczystymi zagraniami jest walidacja tekstu wpisywanego przez użytkownika za pomocą wyrażeń regularnych.Metodą, która wykonuje za nas odpowiednią walidację, jest przedstawiona poniżej metoda Strip:

using System.Text.RegularExpressions;

public static string Strip(string text)

{

    return Regex.Replace(text, @"<(.|\n)*?>", string.Empty);

}

 Stosowanie przez nas tej metody, na każdym "stringu" wpisywanym przez użytkownika, przed zapisaniem go do bazy danych, nie będzie miało zauważalnego wpływu na wydajność, za to zdecydowanie podniesie bezpieczeństwo naszej aplikacji.