nechapu, co to je za zhuverilost, ale poptam se: wpf/mvvm/c#/entity framework - data grid na "formu" - vygeneruji se do nej data, ktera se do "save list" nehazeji do databaze, jeden ze sloupcu je interne vysledkem "ToString()" na komplexnim typu. na vsech testovacich (i testovaci terminalovy server slape dobre) a vyvojarskych prostredich s tim neni nejmensi problem, nikdy. ale po releasu se to na finalnim terminalovym serveru (uzivatelel aplikaci jedou pres RDPcka) zacne matlat takovym zpusobem, ze dokud se to neulozi do databaze a okno se neotevre znovu, tak ten "ToString()" sloupec nezobrauzuje lautr nic... ale evidentne to v tech obektech ma, protoze vsehcny ostatni data tam jsou, polozka spravne reaguje na dvojklik a podobne. [a nepomuze to ani pustit primo z terminaloveho serveru bez RDP]
vubec netusim, jak ulovit, kde je chyba a vubec netusim, ktera cast to muze zpusobovat. nevidel nekdy nekdo neco podobneho.
dik (pripadne zkusim popsat jeste presneji, ale je to fakt haluz)

otazka ale je, ako zistim velkost mdf suboru.
kedze db je federovana, ... teda tych mdf je viac.
TENCOKACISTROMY

TENCOKACISTROMY: jo to dava zmysel

VIRTUALVOID: Nj, ale k cemu ti tohle cislo jako provozovatli je?
Kdyz nastavim fillfactor=01 na cluter_index, tak mi pocet stranek dost zasadne naroste a tim i velikost dotycneho souboru. Je sice hezky, ze skutecnejma datama zaplnim jen 1% ze stranek, ale i tak to na tom disku nekde musi bejt ulozeny.

TENCOKACISTROMY:

ono to az take tazke nieje, objavil som tento select :
select sum(reserved_page_count) * 8.0 / 1024 from sys.dm_db_partition_stats
GO

select  sys.objects.name, sum(reserved_page_count) * 8.0 / 1024 
from  sys.dm_db_partition_stats, sys.objects 
where sys.dm_db_partition_stats.object_id = sys.objects.object_id 
group by sys.objects.name
go

takze som bol zmeteny :)

TENCOKACISTROMY: Jeste dalsi vec je ldf. Transakcni log muze bezet v nekolika rezimech. Od "simple" kdy je ten soubor fakt malej po "full" kdy ten soubor klidne muze bejt 100x vetsi nez mdf.

VIRTUALVOID: Na 99% to je velikost mdf.
1) Mnozstvi dat v tabulkach se meri docela blbe.
2) Velikost mdf je zavisla na tom jaky dodatecny objekty k tabulkam mas (napr. indexy a jejich fillfactory).

nevie niekto nahodou, co sa billuje v SQL Azure, ci ide o velkost dat, ktore su v tables, alebo velkost mdf, teda samotneho file db ?
dik

vim ze to sem asi nepatri, ale je to mimoradne surne, tak kdyby to nekoho zaujalo...
[ OFFERING WORKNABÍZÍM PRÁCI: ASAP: C#, 2 měsíční projekt v Německu / Německo, Olomoucko ]

NECROMAN: Zkusil bych to u aspone.cz, tam radi nasazuji nove MS produkty jeste pred RTM verzemi. Na webu o tom sice nic nepisou, ale treba tam uz neco zkousi.

nevite o nejakem free hostingu na asp.net 4.5 beta na pokusy? :)

Nestalo se vam nekomu, ze po instalaci .NET 4 na webserveru se ostatni web aplikace zpomalily?

H_U_N_T_E_R: ano to viem, a prave som sa hrabal v tej definicii tej query a nevidim tam nic spojene s nejakym predchadzajucim checkinom, vsetko sa to viaze len na prvotne nastavenia tasku(work itemu), z coho tu "dynamicku"(filter podla toho ci uz je task v develop resolved ale este nie v main) query asi nezlozim, alebo ano?

DARKREIDER: když dáváš commit a asociuješ task, tak nahoře v comboboxu vybíráš query. Ty query se dají definovat v TeamExploreru. Tam by to vyfiltrovat jít mělo (kdyby nepomohlo to klikátko, tak ještě pobinguj - dá se to nějak psát i v něčem vzdáleně podobným t-sql a dostaneš se tím ještě hlouběji)

studujem ten check in dialog a nevidim tam nic cim by som pri komite doplnkovo oznacil task, bolo by dostacujuce keby slo vyrobit nejaku filtracnu query, ktora by mi po merge do main a naslednom pokuse o komit vybrala v zozname taskov a US a bugov len tie polozky, ktore som v Develope komitol ale v main este nie, ale podla toho ako sa v tom hrabem tam asi nic take nie je. Resp to tam nevidim, nie som v tom tfs zrovna kovany.

nebo nejaky tagy, to tam musi byt

PJOTRIK: Su tam User Story ktore pod sebou zahrnuju podtasky, co by v dokonalom svete mohlo fungovat ako pises, ale u nas na firme to zial funguje tak ze v 90tich percentach jedna uloha je jeden User Story bez pod taskou co mi tento pristup komplikuj a dalej aj bugy by museli byt nejakym sposobom v takychto skupinach, co sa rozhodne nestane, aj keby to v TFS slo.

nebo neco jako oznaceni releasu, pak by stacilo si vyfiltrovat tasky pro konkretni release a muzes je najednou resolve

DARKREIDER: TFS neznam, ale neni tam neco treba jako high-level tasky? Ze bys pod-tasky oznacoval jako hotovy hnedka a nad-task az kdyz se merguje do Main.

Caute,

mam skromnu otazku. Uz sa tu kedysi davno TFS spominalo. Pouzivame vo firme Main vetvu a Develop vetvu. pricem v Develop sa prudko vyvija a nasledne merguje do Main.

Problem je, ze system ktorym sa eviduju splnene tasky je dost debilny. Aktualne dostanem v TFS Task, ten splnim v Develope, pri komite do Developu ale nemozem Task oznacit ako Resolved ale iba ako Associated. A az budem vsetky hotove tasky vramci UserStory komitovat do Main, tak ich mozem pri komite mergu oznacit za Resolved.

Vdaka tomu je v tom TFS vidiet kedy sa dostal do Main ten ktory task a v ktorom builde skoncil. Ak by sa to priradilo ako resolved uz v Develope tka o tom Main nebude vediet.

Lenze vdaka tomu ja mam 60 taskov, 20 vyriesim a stale mi strasia v zozname Taskov, lebo niesu Resolved. A ked MErgujem do Main, tak stejne musim mat niekde na papiery napisane, ktore tasky som uz vlastne spravil a mam ich pri komite do main oznacit ako resolved.

= OPRUZ

Odbornici od nas mi tvrdia, ze inak to nejde, co mi pride krajne dementne. Ja by som si predstavoval, ze pri develope pekne task oznacim ako hotovy, zmizne mi zo zoznamu a pri merge do Main sa mi k tomu komitu pripoji automaticky. Mate k tomu niekto nejaky postreh? Alebo aspon nejake ine/lepsie riesenie ako viest asociaciu taskov a ich flow vetvami, bez toho aby som to vzdy musel rucne priradovat ja a prehrabavat sa v tonach taskov. diky moc.