Programming with C#

MSDN spune ca proprietatea IsPostBack e o valoare care indica daca pagina este creata pentru a fi raspunsul postbackului unui client sau pagina este creata si accesata pentru prima data. Cuvantul cheie e postback, de fapt ce inseamna acest postback. Perceptia generala e ca IsPostBack e true atunci cand utilizatorul da click pe un buton sau pe un control dintr-o anumita pagina, care are setata proprietatea AutoPostBack = true (dropdown de exemplu).. sau hai sa zicem pe orice control cu evenimente care se instantiaza pe server in urma unei actiuni a utilizatorului in fereastra browserului. Mai altfel zis, Popescu, avid de monden, deschide browseru, scrie http://www.web.com/Clasamente.aspx, ii apare pagina frumoasa, care il invita sa dea click pentru a vedea clasamentul celor mai naspa vedete din Romania. Developerul presupune la PageLoad ca Page.IsPostBack e true, adica Popescu sigur avea deja pagina incarcata in browser, inainte de a accesa clasamentul celor mai naspa vedete din Romani

Am dat de un mic bug in LINQ to SQL, ce m-a facut sa-mi regandesc o abordare dintr-un anumit proiect. Eroarea apare in interiorul DataContext si anume la nivelul asocierii dintre clasele mapate pe tabele in scopul de a evidentia relatia 1:n. Sa explic insa cu un exemplu. Se da o baza de date cu trei tabele, o tabela cu categorii, o tabela cu produse si o tabela History, care contine istoria operatiilor pe celelalte doua. Pentru o anumita inregistrare din Products sau Categories vor exista una sau mai multe intrari(sau niciuna) in tabela History. Stiind un anumit HistoryGUID din Products sau Categories se pot afla inregistrarile din History, adica istoria operatiilor facute pentru o anumita inregistrare din oricare tabele. Cum HistoryGUID este generat automat de SQL Server cu newid(), la inserarea unei noi inregistrari intr-o tabela din cele doua, atunci e asigurata unicitatea lui la nivel de baza de date, conditie necesara pentru a identifica corect cumulul de inregistrari in History a