Piotr Szczepanik – programowanie (.Net, C#, SQL), administracja, IT

Chcemy zmienić COLLATION dla naszej bazy danych, ale SQL Server zwraca nam komunikat: The database could not be exclusively locked to perform the operation.

Możemy ominąć ten problem zmieniając przed wykonaniem operacji zmiany COLLATION przestawiamy tryb pracy bazy danych na single user, a po wykonaniu operacji z powrotem na multi user.

 T-SQL | 
 kopiuj kod |
?
 
1
ALTER DATABASE [nazwa bazy] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
2
ALTER DATABASE [nazwa bazy] COLLATE [nazwa COLLATION]
3
ALTER DATABASE [nazwa bazy] SET MULTI_USER

Pomimo tego, iż Response.Redirect oraz Server.Transfer są dosyć często używanymi metodami przez programistów ASP.Net, często zdarza się, że tak naprawdę nie wiemy co się dzieje wskutek ich użycia.

Response.Redirect

Metoda ta nakazuje klientowi (przeglądarce internetowej) odwiedzenie danej lokalizacji URL. W praktyce po stronie użytkownika skutek jest taki sam jak byśmy wpisali nowy adres do paska adresu.

Jak właściwie to się odbywa? W momencie użycia Response.Redirect przeglądarka otrzymuje od serwera nagłówek HTTP podobny do poniższego (w nagłówku znajdują się również dodatkowe informacje, które w tym miejscu, akurat są bez znaczenia dla wytłumaczenia tematu):

HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.0
Location: new-url/new-page.aspx

Ten nagłówek informuje przeglądarkę, iż żądana strona znajduje się pod nową lokalizacją. Po tej informacji przeglądarka wykonuje kolejne żądanie (Request), tym razem pod lokalizację przekazaną w nagłówku.

Dzięki temu mechanizmowi możemy przekierowywać klienta zarówno na strony znajdujące się na naszym serwerze jak i na pełne adresy URL (np. http://www.photoartis.pl). Nowy URL może zawierać również tzw. QueryString, m.in. dzięki czemu możemy uzyskać przekazywanie informacji między stronami.

Należy pamiętać, że w momencie zastosowania Response.Redirect wszelkie pola z POST’a zostają utracone (jest to logiczne wskutek opisanych powyżej działań, ale warto o tym przypomnieć).

Server.Transfer

Ta metoda odbywa się całkowicie po stronie serwera. Np. przeglądarka wykonuje żądanie o stronę A.aspx. Aplikacja wywołuje metodę Server.Transfer(“B.aspx”). W rezultacie serwer zwraca do klienta zawartość strony B.aspx. W tym przypadku przeglądarka nadal myśli, że znajduje się na stronie A.aspx. Wskutek powyższego mechanizmu w pasku adresu przeglądarki będzie widniał URL do strony A.aspx.

Dzięki temu mechanizmowi otrzymujemy m.in. fakt, iż nie jest wykonywane kolejne żądanie HTTP po stronie klienta. Również zachowywane są wszystkie pola z POST’a.
Należy jednak pamiętać, że jeżeli strona wywołująca “Transfer” przed ta operacją zapisze coś do Response buffer to w rezultacie otrzymamy wynik z danymi zapisanymi do bufora oraz zawartością strony, na którą wykonaliśmy metodę Transfer. W takich przypadkach możemy po prostu przed wywołaniem metody przeprowadzić czyszczenie buforu Response.

Pamiętajmy również, że Server.Transfer nie umożliwia przekierowania na strony poza nasz serwer.

Często zdarza się, iż wrzucamy na naszą WebForm kontrolkę TextBox, a zaraz obok niej przycisk, który wywołuje jakąś akcję związaną z treścią wpisaną do kontrolki, np. pole wyszukiwania.

Co zrobić, żeby użytkownik zamiast klikania w przycisk wcisnął Enter po wpisaniu treści do pola TextBox ?

Poniżej przedstawię dwa sposoby:

Sposób 1 – kontrolka Panel

Umieszczamy obydwie kontrolki wewnątrz asp:Panel, której atrybut defaultButton ustawiamy na nasz przycisk.

 ASP | 
 kopiuj kod |
?
 
1
<asp:panel defaultbutton="btnSearch runat=">
2
    <asp:textbox id="textbox1" runat="server">
3
    <asp:button id="btnSearch" runat="server" text="Szukaj">
4
</asp:button></asp:textbox></asp:panel>

Sposób 2 - JavaScript

Na kontrolce TextBox dodajemy obsługę zdarzenia OnClick (np. w zdarzeniu PageLoad).

 Javascript | 
 kopiuj kod |
?
 
01
textbox1.Attributes.Add("onkeydown", 
02
            @"if(event.which || event.keyCode){
03
                  if ((event.which == 13) || (event.keyCode == 13)) {
04
                      document.getElementById('" + btnSearch.UniqueID.Replace('$', '_') + 
05
                      "').click();
06
                      return false;
07
                      }
08
                } else {
09
                    return true
10
                }; ");

Większość osób posługujących się SQL’em wie do czego służy UNION, mało tego często zdarza się, że go używa.

Jednak jak pokazuje doświadczenie, nie każdy wie jaka różnica jest pomiędzy UNION, a UNION ALL. W rezultacie przy pisaniu zapytania stosuje UNION, chociażby z racji tego, iż jest krótsze .

W skrócie UNION ALL łączy wszystkie rekordy z zapytań, natomiast UNION dokonuje filtracji i odrzuca duplikujące się rekordy (DISTINCT).

W przypadku zbioru danych, w którym nie występują duplikaty dane wynikowe będą takie same, jednak samo obciążenie wywołane zapytaniem jest inne, na niekorzyść UNION.

Co z tego wynika? Jeżeli jesteśmy pewni, że dane znajdujące się w łączonych przez nas zapytaniach nie posiadają duplikatów / bądź też nie przeszkadza nam obecność duplikatów zawsze stosujmy UNION ALL.

Załóżmy, iż mamy witrynę WWW, bądź dwie, które korzystają tylko i wyłącznie z protokołu https.
Użytkownicy jednak uparcie wpisują w pasku adresu przeglądarki http.

Przydał by się mechanizm, który po odwołaniu na odpowiedni adres po protokole http przekieruje na daną lokalizację przy użyciu protokołu https.

Poniżej przykład skryptu w ASP realizujący to zadanie, dla dwóch różnych adresów. Skrypt ten podpinamy pod daną witrynę (np. jako default.aspx).

 Visual Basic | 
 kopiuj kod |
?
 
01
<% Language=VBScript %>
02
<%
03
Dim host
04
host = Request.ServerVariables("HTTP_HOST")
05
Select Case host
06
    Case "poczta.domenka.pl"
07
        Response.Redirect("https://poczta.domenka.pl/owa")
08
    Case "remote.domenka.pl"
09
        Response.Redirect("https://remote.domenka.pl/remote")
10
End Select
11
%>