łaczenie kolumn w DataGridView za pomocą LINQ

Witam!

Zwracam się do was z prośbą o pomoc przy łączeniu kolumn w widoku DataGridView. Moja kontrolka DataGridView jest tworzona, a nastepnie definiowana poprzez zapytanie Linq'u, które wygląda nastepująco:

from przekazanie in bazaBudSystem.Przekazania
                select new
                {
                    Numer = przekazanie.id,
                    NazwaSprzętu = przekazanie.Sprzet.nazwaSprzetu,
                    NumerEwidencyjny = przekazanie.Sprzet.nrEwidencyjny,
                    NumerSeryjny = przekazanie.Sprzet.nrSeryjny,
                    MagazynŹródłowy = przekazanie.Magazyny.nazwa,
                    //MagazynierŹródłowy = (przekazanie.Uzytkownicy.imie) + " " + (przekazanie.Uzytkownicy.nazwisko),
                    DataPrzekazania = przekazanie.dataPrzekazania,
                    Status = przekazanie.statusPrzekazania,
                    MagazynDocelowy = przekazanie.Magazyny1.nazwa,
                    //MagazynierDocelowy = (przekazanie.Uzytkownicy1.imie) + " " + (przekazanie.Uzytkownicy1.nazwisko),
                    DataAkceptacji = przekazanie.dataAkceptacji,
                    DataOdrzucenia = przekazanie.dataOdrzucenia,
                    Opis = przekazanie.opis,
                };

Jak widać, chce połączyć kolumny imie i nazwisko w dwóch miejscach, aczkolwiek linijki, które tu są wykomentowane są źle, a ja nigdzie nie znalazłem informacji na temat łączenia kolumn w zapytaniu Linq. Może wy wiecie jak to zrobić?

Nie widze powodu dla ktorego to mialoby byc zle. operacje "sklejania stringow" sa przez wiekszosc providerow linq obslugiwane poprawnie. jakie dostajesz komuniakty o bledach kiedy probujesz ich uzyc?

edit: ah, i jaki provider linq? linq2xml? linq2sql? entity framework? nhibernate? devexpress xpo? inny?

provider EntityFramework :)

jak tylko tak zrobie to po odpaleniu formatki ukazuje sie pusty DataGridView(taki sam widok jak w trakcie projektowania formatki), mimo iż sa rekordy w tej tabeli, i żadnego błędu nie ma

niestety, nie mam juz tyle czasu zeby teraz wszystko odpalac i sprawdzac, ale w przeciwienstwie do linq2sql i innych, EFka akurat nie lubi wlasnych projekcji i przy tworzeniu aninomowych new{} w locie czasami ma fochy.. chociaz wydaje mi sie ze takie proste sklejanie wilokrotnie robilem i nie bylo problemow.. ale pamiec czasem zawodzi

standardowym i czestym problemem EFki sa nawigacje po relacjach.
mozliwe, ze z jakiegos powodu ten new jest realizowany po stronie klienta a nie na serwerze sql, i ze EFce ze "zapomnialo sie" do zestawu odpytywanego doczepic nawigacji po ".Uzytkownicy". w takim przypadku przekazanie.Uzytkownicy == null gdyz UzytkownicyReference.IsLoaded = false, i sumowanie stringow zwrocic mogloby null.. chociaz raczej powinno byloby walnac nullreferenceexception.. eh. szczerze, strasznie dziwne zachowanie, strzelalbym ze blad faktyczny jest gdzies idziej.. w danych na bazie imiona i nazwiska na pewno masz nie null?:)) Albo ze blad jest gdzies na "'warstwie" databindowania listy obiektow do widoku.. sprobuj odkomentowac dodawanie, odebrac wynik zapytania do jakiejs tablicy czy listy i obejrzec elementy czy faktycznie maja null'owe pola magazynierow

A, no i jesli chodzi o taka opcje, ze EFka nie dojoinowala navigationproperty, to => from przekazanie in bazaBudSystem.Przekazania.include("Uzytkownicy").include("Uzytkownicy1"). jednak zdziwilbym sie troche gdyby to faktycznie pomoglo. Konstrukcja linq raczej wskazuje ze wszystko powinno bylo byc odpalone na bazie, ktora powinna sobie ze sklejeniem poradzic.. O, mozesz tez na bazie odpalic profilera i podejrzec jakie LINQ+EF wygenerowalo koncowe faktyczne zapytanie SQL -- po tym wszystko duzo sie wyjasni

Wnioskując z tego co piszesz EFka w moim przekonaniu aż za często "zapomina" o tabelach wiazanych, szczególnie jak sie chce miec dostep do tabeli poprzez jej klucz obcy z innej tabeli.

Odpaliłem Profilera, ale on nie przechwycił żadnego zapytania do bazy, wtedy gdy łączenie kolumn jest odkomentowane. To jest naprawde dziwne. Na zdrowy rozumm wszystko jest podane, nazwa kolumny łączonej, kolumny składowe, forma w jakiej mają byc wyświetlone dane w kolumnie łączonej nawet, a tu lipa - nic nie widać w dalszym ciągu.

słowem WTF!
Jak rozumiem, gdy -są- zakomentowane, to profiler łapie zapytanie?
Jeśli tak, to jedyne co mi przychodzi na mysl co moze sie dziac, to.... ze ten fragment kodu rzuca wyjatkiem podczas generowania tekstu SQL i do zapytania nie dochodzi w ogole.
Możesz to banalnie prosto sprawdzic, wybacz banal, ale napiszę:

List<...> tmp;
try{  tmp = (from .... in ....
        ....... select. ...).ToList();
} 
catch(exception ex)
{  int wait = 0; }   //<- tutaj breakpoint
mojakontorlka.datasource = tmp;

mozliwe ze juz spradzales czy leca wyjatki, albo ze debugger Ci zadnego nie zglasza, ale jesli np. piszesz w WPF, to mozna je naprawde bardzo latwo przegapic, poniewaz wiekszosc z nich, zwlaszcza te w ItemSource'ach albo Bindingach albo EventHandlerach - framework je po prostu .. cichaczem wygasza, i co najwyzej w panelu "output" dostajesz jednolinijkowy komunikat ze "o, byl blad NullReferenceException" a program na to kij z tym, lecimy dalej..

em.. wracajac do tematu - jedyny powod jaki widze dla ktorego SQL mogl sie nie wygenerowac, to wyjatek rzucany przez providera LINQ. W tekscie tego wyajtku bedize dokladnie wyjasnione, czego nie byl on w stanie obsluzyc (np. rzutowanie, np. operator+, np. "projection" czyli select/new anonim{} itp)

coś mi świta, na ile pamietam EFkę, że EFka wymaga, aby kazdy wynik selecta byl typem zarzadzanym przez dany ObjectContext, i ze EFka w ogole nie obsluguje swoich wlasnych "projekcjii" new anonim{}.. acz ta wizja ktora mi sie pamięta, stoi w sprzecznosci z tym, że bez plusów Ci działa poprawnie.. nie pamietam o co chodzilo dokladnie z nieobslugiwaniem projekcji..:( moze mi sie za pare godzin przypomni.. sprwdz przedewsztkim tresc wyjatku

Czy magazynier źródłowy i docelowy zawsze są określeni (na chłopską logikę powinni, ale nie ręczę za twoje dane :)).
Wykonaj może zapytanie ze złączeniami, ja EF aż tak nie zgłębiałem.
Linq:

from przekazanie in bazaBudSystem.Przekazania
join mZrodlowy in bazaBudSystem.Uzytkownicy on przekazanie.MagazynierŹródłowyID equal mZrodlowy.ID
join mDocelowy in bazaBudSystem.Uzytkownicy on przekazanie.MagazynierDocelowyID equal mDocelowy.ID
select new
                {
                    Numer = przekazanie.id,
                    NazwaSprzętu = przekazanie.Sprzet.nazwaSprzetu,
                    NumerEwidencyjny = przekazanie.Sprzet.nrEwidencyjny,
                    NumerSeryjny = przekazanie.Sprzet.nrSeryjny,
                    MagazynŹródłowy = przekazanie.Magazyny.nazwa,
                    MagazynierŹródłowy = mZrodlowy.imie + " " + mZrodlowy.nazwisko,
                    DataPrzekazania = przekazanie.dataPrzekazania,
                    Status = przekazanie.statusPrzekazania,
                    MagazynDocelowy = przekazanie.Magazyny1.nazwa,
                    MagazynierDocelowy = mDocelowy.imie + " " + mDocelowy.nazwisko,
                    DataAkceptacji = przekazanie.dataAkceptacji,
                    DataOdrzucenia = przekazanie.dataOdrzucenia,
                    Opis = przekazanie.opis,
                };

Tak, magazynierzy są i muszą byc zawsze uzupełniani. Niestety to rozwiązanie daje identyczny efekt - dalej DataGridView nic nie pokazuje :/

A zapytanie w sql profilerze jakies leci?
A jakis exception?
Moze masz cos zle z mapowaniem struktury? wyklikaj jeszcze raz diagram

Diagram profilaktycznie wyklikałem jeszcze raz. Tym razem w Profilerze ukazało sie takie oto zapytanie:

<image>http://img163.imageshack.us/img163/9276/profilert.jpg (screen z profilera)
</image>
Wyjątku żadnego nie stwierdziłem :)

Nie wiem na podstawie jakiego linq query to zostało wygenerowane, ale zauważ że to niezły syf od strony sql. Masz tu masę niepotrzebnych złączeń.

Jesli chodzi o same niepotrzebne łączenia to taka chyba uroda EF bo każde zapytanie tworzone za pomocą tego framework'a generuje duzo niepotrzebnych śmieci w zapytaniu SQL'owym :/

Wrzuciłem screen mojego profilera, zamiast kodu w poprzendnim moim poscie.

ok, super, czyli jedna rzecz z uszkodzonym EDMX zostala rozwiazana, skoro tez zapytanie polecialo do bazy w ogole.
zwroc uwage, ze w zapytaniu masz LEFTJOIN oraz ze pojawiaja sie zlepienia stringow.
to znaczy, ze NULL'owy wynik moze pojawic sie z dwoch powodow:

• po pierwsze, jezeli chociaz jedno z IMIE albo NAZWISKO bedzie rowne NULL, to zgodnie ze standardem SQL, wynik zlepienia NULL+string = null, i caly wynik sklejania bedzie null, mimo ze jakies napisy moga byc w tym-drugim napisie
• jezeli LEFTJOIN nie dowiąże żadnego wiersza, do danego "przekazanie", to kolumny z brakujacego wiersza sa trkatowane jako NULL, patrz wyzej

trzecia opcja jest taka, ze na bazie wszystko wykonalo sie poprawnie, a cos w Twoim kodzie świruje.

skoro masz juz to zapytanie złapane w profilerze - wykonaj prosty test, szczerze mowiac, myslalem ze sam na to wpadniesz, ale za pierwszym razem to nikt o tym nie pomysli:)
SKOPIUJ to zapytanie z profilera, odpal je recznie w SqlServer ManagementStudio (new query, use baza, wklej, F5) i zobacz, jaki bedize jesgo wynik. To Ci natychmiast odpowie, czy zapytanie jest sensowne i czy generuje samo z siebie NULL jako wyniki sklejenia imie+nazwisko

mam nadzieje, ze okaze sie ze ono wygenerowalo null'e..

jesli nie ono, i jesli wsyzstkie wiersze wynikowe mialy wynik imie+nazwisko != null, to idz do kodu, i odbierz tak jak Ci wczesniej napisalem wszystkie wyniki tego zapytania do List<Przekazanie>, a nastepnie obejrzyj w debuggerze obiekty na tej liscie i sprawdz czy ich wartosci sa null czy nie.

jesli beda null, to dalej masz gdzies blad w EDMX, co bedzie niemile do sprawdzenia.. albo provider EF lub SSQL świruje, co bedzie jeszcze bardziej nie mile.
btw. jak rozumiem, zadne wyjatki tam gdzie mowilismy nie lecialy?
a jesl nie beda null, to masz problem z (data)bindingami z grida do listy, co raczej chyba powinienes dac rade znalezc, bo pewnie jest zwykla literowka gdzies.

ps. a tak w ogole, ja wiem i Ty pewnie tez, i pewnie wszysscy wiedza, ze C# Java i im podobne obsluguja "wewnetrznie" Unicode'a, i ze mozesz klasy i meody nawet nazywac chinskimi krzaczkami, ale jednak przyjmuje sie zwyczajowo, żeby w publicznych nazwach jednak nie umieszczac znakow innych niz lacinskie.. z tego glupiego powodu, ze np. Designerze łatwo jest wpisac zrodlowy zamiast źródłowy, a i z innego glupiego powodu, ze ... publicznych nazw moze potem uzywac osoba, ktora np. nie zna Twojego języka i nie widzi róźnicy między Ż a Ź, nie mowiac o nas i chinskich krzaczkach:)

już sam nie wiem co o tym mysleć...

SQL Management Studio po uruchomieniu skopiowanego z Profilera zapytania wygenerowanego przez Linq + EF, wywalił taki błąd:

The data types text and nvarchar are incompatible in the add operator.

i podświetlił tą linijkę:

[Extent6].[imie] + N' ' + [Extent7].[nazwisko] AS [C2], 

tyle tylko ze żadne z łączonych pól nie jest typu nvarchar tylko text. Zmieniłem te typy na nvarchar, ale efekt ten sam. No chyba że chodzi mu o przerwe która musi być między imieniem a nazwiskiem, ale to raczej trafia jako string, któremu bliżej do typu text w SQLu niż do nvarchar.