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ě.
Takovoudle prima výjimku dostaneme, pokud voláme System.IO.Directory.CreateDirectory(String path) a nemáme přístupová práva alespoň na prohlížení všech nadřazených složek, typicky třeba chceme-li vytvořit novou složku z webové aplikace.
Directory.CreateDirectory() totiž neslouží jen pro založení jedné složky, ale pokud je potřeba, vytvoří celou požadovanou cestu, založí všechny potřebné složky. Základní potíž je v tom, že si nekontroluje existenci složek zdola, ale shora. Takže požadavek na založení složky C:\Inetpub\wwwroot\WebApplication\slozka\ kontroluje nejprve existenci C:\, pak C:\Inetpub\, pak C:\Inetpub\wwwroot\. No a pokud nemáme práva alespoň LIST na celou trasu, tak jsme v loji…
Jaký je rozdíl mezi HttpContext.Current.Cache oproti HttpRuntime.Cache?
Zdá se to být jednoduché, HttpContext.Cache dělá
public Cache get_Cache()
{
return HttpRuntime.Cache;
}
Proč tedy používat HttpContext.Current.Cache?
Není důvod!!! Správné použití je HttpRuntime.Cache !!!
Když pomineme režii na vyhodnocení HttpContext.Current, tak je tu ještě jeden zcela zásadní důvod, proč používat HttpRuntime.Cache. Ten totiž funguje i v nových threadech, kde je HttpContext.Current null. A nejenom to, funguje dokonce i mimo webové aplikace, třeba v konzolovce.
Viz též
HAVIT Knowledge Base 