Mozilla: nefunguje window.navigate(‚url‘)

Mozilla navigate(‚url‘) nepodporuje.

Místo toho je potřeba použít standardní

window.location.href = 'url';

…což funguje i v IE.

BoundField částečně ignoruje DataFormatString

Problém je v tom, že na BoundField je před formátováním aplikován HtmlEncode. Je to sicereportovaný a uznaný bug (špatně navrženo), nicméně z důvodu zpětné kompatibility budoucích verzí .NET Frameworku to už zřejmě zůstane v této podobě.

BoundField v GridView tedy ve výchozím nastavení nesprávně vyhodnotí DataFormatString u dat, čísel, atp. – například z hodnoty 0,123456 a formátu „aa {0:n1}“ udělá „aa 0,123456“.
Pomůže nastavit HtmlEncode = „false“, tedy vypnout onen problematický HtmlEncode.

<asp:BoundField
   DataField="MyField"
   DataFormatString="{0:n2}"
   HtmlEncode="false"
/>

NUMLOCK při startu Windows / po přihlášení

Spusťte Registry editor a najděte klíč HKEY_CURRENT_USER\Control Panel\Keyboard a nastavte hodnotu InitialKeyboardIndicators na 2. Tímto zapnete NUMLOCK při přihlášení.

[HKEY_CURRENT_USER\Control Panel\Keyboard]
"InitialKeyboardIndicators"=2

Pokud chcete zapnout NUMLOCK již při startu Windows, nastavte v klíči HKEY_USER\.DEFAULT\Control Panel\Keyboard hodnotu InitialKeyboardIndicators na 2.

[HKEY_USER\.DEFAULT\Control Panel\Keyboard]
"InitialKeyboardIndicators"=2

Jinou možností bez použití Registry editoru je prý přihlásit se jako administrátor nebo jako uživatel s administrátorskými právy a zapnout NumLock. Poté stačí restartovat Windows a při dalším startu se bude zapínat automaticky. Mně to ale většinou nepomůže, zabere až změna v registry…

ASP.NET WebForm Page Lifecycle Diagram (Léon Andianarivony)

Viz též můj podrobný diagram včetně request fází.

image

TRUNCATE TABLE vs. DELETE

Příkaz TRUNCATE TABLE vyprázdní tabulku a má tak efekt podobný příkazu DELETE (bez omezujících podmínek). Ve skutečnosti je však jejich funkce dosti odlišná.

TRUNCATE TABLE je ale rychlejší, používá méně systémových prostředků a méně prostředků transakčního logu, než DELETE (neloguje mazání každé jednotlivé řádky).

TRUNCATE TABLE navíc vyresetuje identity counter na počáteční hodnotu!!!

TRUNCATE TABLE neaktivuje TRIGGER !!!

DELETE vymaže řádky po jednom a do transaction-logu se zaznamená každé jednotlivé vymazání samostatně. Naproti tomu TRUNCATE TABLE vymaže data dealokací (uvolněním) datových stránek (data pages) použitých pro tabulku a do transaction-logu jsou zaznamenány jen tyto dealokace.

Exchange neodesílá, snaží se doručovat na divné IP adresy

Symptom

Pozoruhodné chování Exchange 2003 serveru. Neodchází maily do věšiny domén, zbytek zůstává ve frontě. Po bližším ohledání je v eventech vidět, že Exchange na některé pokusy vyhodí chybu, že mu protější strana neodpovídá. Z některých eventů je poznat, že komunikuje s podivnými IP adresami protější domény, které neodpovídají MX záznamům, ale jiným adresám v cílové doméně (nejpíš hlavní adresy domény, blíže jsem neprozkoumal).

Do domén, kde se adresa SMTP serveru náhodou shoduje s takto určenou IP adresou Exchange serveru, tak tam jsou maily doručeny v pohodě.

Příčina

Toto podivuhodné chování se projevilo na stroji Windows 2003 Server R2, který neměl na síťovém rozhraní nastaven DNS server. DNS služba však na něm běžela (to však nemusí být podstatné).

Každopádně stačilo nastavit DNS sám na sebe a vše se hned rozjelo. Čím resolvoval doposud, těžko říct. Očekával bych, že nebude resolvovat vůbec, ale nějak resolvoval…

Uložení výsledku stored procedury pomocí SELECT INTO

Když neznáme přesnou strukturu výsledku stored procedury, nemůžeme použít CREATE TABLE a INSERT … EXEC. Dá se to obejít pomocí OPENQUERY:

exec sp_serveroption [SERVER_NAME] , 'data access', 'true'

SELECT * INTO #W FROM OPENQUERY([SERVER_NAME], 'exec sp_who')
SELECT * FROM #W

SQL: Doplňování (padding) čísel nulami zleva na pevný počet míst (15 -> 00015)

Možná to jde lépe, ale co třeba takto:

= REPLACE(STR(15, 5, 0), ' ', '0')

Funkce STR(num, length, decimals) převede číslo na řetězec určené délky (doplněný zleva mezerami) a s daným počtem desetinných míst.

Nebo takto?

= RIGHT('00000' + cislo, 5)

Většinou si formátování řešíme až v prezentační vrstvě, ale někdy se to může hodit…

SQL: Určení věku osoby z data narození

Vypadá to jako triviální problém, nicméně triviální řešení zde nejsou správná.

Nejprve tedy správné řešení:

/*
   Vrátí věk ke vztažnému datu určený dle data narození.
*/
ALTER FUNCTION dbo.Age 
(
   @DatumNarozeni smalldatetime,
   @VztazneDatum smalldatetime
)
RETURNS tinyint
AS
BEGIN
   RETURN DATEDIFF(year, @DatumNarozeni, @VztazneDatum)
      - (CASE WHEN (100 * MONTH(@VztazneDatum) + DAY(@VztazneDatum)) < (100 * MONTH(@DatumNarozeni) + DAY(@DatumNarozeni))
              THEN 1 ELSE 0 END)
END

A pár ukázek špatných řešení:

DATEDIFF(year, @birthdate, @enddate)

SELECT DATEDIFF (year, @birthdate, @endDate)
  - CASE WHEN DATEPART(dy, @birthdate) <= DATEPART(dy, @endDate) THEN 1 ELSE 0 END

První pokus od sebe jen odečte letošní letopočet od letopočtu narození.
Druhý pokus zase nefunguje korektně s přestupnými roky, protože pak není počet dnů od 1.1. stejný.

Cannot resolve collation conflict for UNION operation.

Zajímavá hříčka, která může klidně skončit chybou „Cannot resolve collation conflict for UNION operation.“

SELECT * FROM RealTable INTO #temp WHERE ...

SELECT * FROM #temp
UNION
SELECT * FROM RealTable 

Dejme tomu, že RealTable používá default database collation.
Přestože výše uvedené vypadá, že přeci nemůže být s COLLATION problém, může být.
#temptable se totiž vytváří v databázi tempdb, která může mít jiné collation, než naše user-databáze!!! …a problém je na světě.