STANDART: To je stejny jak s Prahou. IBM se nebere v potaz jako zamestnavatel. :)

DARKREIDER: tak ale třeba IBM má v Brně nejvíc nabídek snad ze všech regionů ne?

STANDART: som sa usadil v Brne, clovek si mysli velke mesto a ono sa to stejne taha do Prahy

DARKREIDER: :) jako doufám že nejsem sám, kdo už vlastně jiné město než Prahu nebere v potaz :)) a slovenštinou jsi mi připoměl, že bych pre Teba mal ponúku aj v Blave keby si mal zaujem?

STANDART: v tychto inzeratoch by mozno stalo za to pisat aj lokalitu, alebo som tu jediny mimo Prazsky?

SHIGORBIRDMAN: a to ani netušíš, jaký další proměnné budou tým tvořit, tohle je ještě minimum :)

SHIGORBIRDMAN: Ve firmě kde teď jsem jsem taky nastoupil jako programátor v Javě. :-D A pak jsem se akorát směrem přes J# hezky přehoupl do C# a v Javě za těch 6 let nenapsal ani čárku ;)

zdravím, cím že budu možná trochu mimo OT tohohle klubu, ale kdyby náhodou někdo sháněl uplatnění se s .NETem (C#) v praxi, pošlete mi email na standartne@gmail.com s předmětem JAVA. V současné době mám cca 5 pozic (od juniorních přes zkušené programátory k seniorním samostatným programátorům (architektům). Prostě kdybyste poptávali nějakýho toho kapříka a programování vás baví, dejte vědět.

Zdar, hledame posily do naseho vyvojovyho tymu ( http://infinitum.cz/novinky/otevreny-pracovni-pozice.html ).

Za dobre odvedenou praci nejen dostanete penize, ale bude vam i dekovat hromada hracu. Prace je to zajimava, rozhodne se nekoduje dokola porad to samy a pracovni kolektiv je v pohode.

Jestli je to OT tak sorry:

Mame v TFS 3 branches a stala se mi zajimava mec. Udelal jsem check-in 3 souborů v prostřední větvi (B). Po merge changesetu to vetve(A) jsem je commitnul i v cilove vetvi. A ted kdyz dam merge z A do B tak ikdyz je nic nezmenilo, tak TFS mi po merge hlasi ze tyto tri soubory maji pending change, ale pritom kdyz je spolu porovnam jsou v obou dvou vetvich identicke.
A kdyz dam check-in a merge zpet, tak jsou opet tyto 3 soubory s pending change, takze bych si je mohl pri merge prehazovat z jedne vetve do druhe neustale dokola.

Ma to nejake reseni nebo nastaveni, jak rict tfs ze tyto soubory jsou stejne, tak at mi je nemerguje

MORMEGIL: Sorry, poslal jsem blbej link. Spravne je tento.

Uvnitr ty funkce nacitam data z ty samy databaze, ale potrebuju, aby do sebe ty transakce nezasahovaly.
Konkretne mi jde o to, aby bez ohledu na to v jake transakci se ta funkce vola, tak aby vzdy nacitala data pomoci "snapshot isolation level". Normalne bych to udelal v ramci procedury v T-SQL, jenze tenhle izolacni level jde aktivovat pouze v pripade, ze ten snapshot isolation level je aktivovanej hned na zacatku spusteni celyho toho skriptu - coz se blbe zajistuje.

TENCOKACISTROMY: No to teda nevím, jak tamta moje otázka souvisí s tvým problémem. :-) Enlist=false říká, že toto připojení se nemá účastnit (případné) právě aktivní distribuované transakce. Chápu dobře, že uvnitř tabulkové funkce se připojuješ někam jinam a DataReaderem tamodtud něco čteš? A jak _chceš_ aby to fungovalo z hlediska transakčnosti? Podle _toho_ musíš navrhovat řešení.

Mam SQL-CLR tabulkova funkci, ktera nacita data a vraci vysledky pres "yield return".
Na SO (link) jsem zjisti ze nastavenim "Enlist=false" v connection stringu mi zacne ten "yield return" fungovat kombinaci s nacitanim dat z datareaderu.

Otazka: Mate nekdo tuseni, jestli je tohle validni a hlavne bezpecny reseni?

DARKREIDER: to prave ne, potrebuji nejak pseudonahodne prerozdelovat polozky do N kolekci podle jmena...ale asi nejsnazsi bude
"name".GetHashCode() % totalCount

Dictionary alebo Hashtable by nepomohlo?

rychly dotaz - mam napr N krat list<string> a novou polozku, kterou chci podle jejiho hashe zaradit do jedne z techto N listu, jak na to?
teoreticky je mi to jasne, seradit listy, zjistit hash, najit zobrazeni z hash => [0,1) a najit mapovani z [0,1) do urciteho listu, ale jak to provest?

JACHYMKO: nedivim se ze to tu sefujes ))))))