Mozilla navigate(‚url‘) nepodporuje.
Místo toho je potřeba použít standardní
window.location.href = 'url';
…což funguje i v IE.
Mozilla navigate(‚url‘) nepodporuje.
Místo toho je potřeba použít standardní
window.location.href = 'url';
…což funguje i v IE.
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"
/>
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…
Viz též můj podrobný diagram včetně request fází.

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.
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ě.
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…
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
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…
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ý.
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ě.