Ja koristim vs 2005. Probaj ovako, treba da radi:

Dim a As New Form1
a.CourseTableAdapter.GetData.DataSet. (pa dalje uzimas sta hoces npr tables(0).rows...)
ako ne posalji ceo kod!

Ovako otprilike (maternji mi je VB, ali cu pokusati C# napamet):
Kod u form1:

Kod u form2:


PS. obrati paznju na velika/mala slova jer ih ne znam napamet.

Probaj Ovako:
Deklarisi promenljivu dataSet1 kao PUBLIC STATIC promenjivu klase FORM1.

i moci ces da joj pristupis iz druge forme bez instanciranja zato sto je STATIC
datagrid1.DataSource = forma.dataSet1;

samo razmisli sta znaci i da li ti odgovara da ti promenjiva dataSet1 bude STATIC.

Nazalost, javlja gresku prilikom build-a u kodu za this.Owner:
D:\My Documents\Visual Studio Projects\MojProjekat\Form2.cs(117): Cannot implicitly convert type 'System.Windows.Forms.Form' to 'MojProjekat.Form1'






Probao sam da promenim dataset iz private u static i vraca sledecu gresku prilikom build-a:
D:\My Documents\Visual Studio Projects\MojProjekat\Form1.cs(71): Static member 'MojProjekat.Form1.dataSet1' cannot be accessed with an instance reference; qualify it with a type name instead.

Pozdrav,
Vlada

Cudno, ja sam ovo ovako radio vise puta, jedino sto je bio VB ali isti princip.

Edit:
Evo upravo sam probao sledece:



i dobijam poruku test

Edit2:
Ali, nakon sto sam probao u C#-u... dobijam istu tu gresku. Ali moze se resiti sa: MyParent = (Form1)this.owner;
E sad, posto nisam bas narocito upucen u C#.. bas me zanima preciznije u cemu je stvar sa implicitnom i eksplicitnom konverzijom, tj. zasto nije isto u VB-u i C#-u

_{[Ovu poruku je menjao Shadowed dana 16.06.2007. u 00:54 GMT+1]}

Uspeo sam da procitam dataSet1 na formi Form2.
U Form1 sam nakon punjenja "dataSet1" otvorio Form2 i za "dataSet1" iz Form2 dodelio vrednost "dataSet1" iz Form1 i to je proslo:



U Form2_Load dogadjaju sam napunio dataGrid i podaci su prikazani...



Hvala puno svima koji su pomogli.
Pozdrav,
Vlada

To sto si uradio je pogresno. Zapravo pogresan dizajn.
Zasto?

Jer po tvom kodu ponovo kreiras i unis DataSet, i on nije isti u odnlus na onaj koji zelis da pozoves.
Da bi to radilo ispravno, moras da negde u kodu Forme1 zapamtis referencu Forme2, i onda da pozoves taj dataSet.

Pozdrav

Slazem se sa ovim, malo je preterano instancirati celokupan form samo da bi dobio dataset iz njega, narocito ako je taj dataset takav da ga korisnik nije menjao u Form1. Ako sadrzi samo podatke ucitane iz baze, onda bolje samo instanciraj sam DataSet u svojoj formi...

Slazem se i ja sa ovim , ali to resenje je specificno za ovaj slucaj (dataset).

Generalna praksa bi bila napraviti staticno polje npr. "public static Form1 MyInstance" u samoj klasi Form1, zatim u konstruktoru za Form1 staviti "Form1.MyInstance = this".

Jos bolje, napraviti static property MyInstance:


Onda ti je u celom projektu na raspolaganju Form1.MyInstance, a samim tim i Form1.MyInstance.dataset1...

Naravno, ovde su i 2 logicna prerequisita...
1. dataset1 i sve ostalo sto ti treba u drugim klasama moraju imati modifier "public", ili napravi property koji omoucava samo "get" za sve sto ti treba (bolja opcija, jer onemogucavas da neko, pa cak i ti, poyebe reference na komponente forme).
2. arhitektura aplikacije mora biti takva da je uvek instanciran samo jedan form1 (tipicno kod STA aplikacija), u suprotnom Form1.MyInstance ce imati samo zadnji instancirani...

Ta budzevina koju si napisao je jedan deo "singleton" paterna. Drugi deo, koji te u stvari stiti od tacke 2 ti fali (singleton klase nemaju public konstruktore). Uzevsi u obzir da svi static objekti zive dok zivi aplikacija ili dok se eksplicitno ne obrisu, ne vidim situaciju u kojoj je stavljanje formova u kvazi-singleton patern prihvatljivo resenje koje nema bolju alternativu...

Ok, ok... sheesh...

Ok, dovoljno blizu

Medjutim, pogledaj sad nasu temu o dispose patternu i vidi koliko je dobro primenjivati ovakve metode. Cross-form koriscenje komponenti (ukljucujuci dataset-ove) ima smisla jedino kod parent-child formova (Ako Form1 instancira form2 pa mu prosledi svoj DataSet, mada je BindingSource preporucljiviji). Drzati eksterne reference na disposable objekte i/ili njihovu decu nije dobra praksa, bar po meni.

Znas kako, ja i verovatno neki odavde imamo praksu da sve sto se tice komunikacije sa bazom drzimo u jednoj klasi. Znaci ono, imas klijentsku aplikaciju, jednu dataset klasu i samo jednu instancu dataseta u celoj aplikaciji koju cuvas u nekom sigleton objektu koji ja cesto zovem deskriptivno "D" (ah taj Delphijev datamodule...) .

Onda radis D.Dataset.xyz, D.bindingSourceXyz.abc, D.ConnectToDb, D.GetServerDateTime...

Mozda to i nije najsrecniji pristup, ali mi je trenutno najbrze i najmanje error prone, dok ne napisem najzad svoj data framework za .net koji cu da koristim u svim aplikacijama. U slucaju ovakvog pristupa tacno znam sta radim, tako da necu disposovati D pre kraja aplikacije (a tada ni nije potrebno), tako da za te potrebe cak i onaj prvi kvazi-singleton nacin je i vise nego dovoljan. Nije kao da ne moze bolje, samo mozda nije potrebno bolje...

Poz, i hvala za tip sa private konstruktorom, ne bi mi nikad palo na pamet da je tako nesto moguce...

Umm, a sta je lose kod metode koju sam ja preporucio (u popravljenoj varijanti)?

Ja je zovem Data, valjda

Inace i po meni ovaj pristup nije los iako u foramama drzim referencu na externi dataset ali tako dobijam na efikasnosti, performansama a i sam rad je olaksan. Naravno treba znati sta se desava sa referencama i objektima.

@viris and nexgo:
Bejah ja jednom Delphi programer i secam se tih 'budzevina", jel to nesto npr kao ovo na slici dole Upravo sad se ubih ovde pokusavajuci da debugujem ovo krme od datamodula. Slazem se sa obojcom da taj pristup radi, ali po meni je taj pristup los jer verovatno niko sem tebe ne razume niti ce ikad razumeti kako to radi Narocito ako prvis ista kompleksnije od iks-oks igrice ili programa za licne cekove ili videklubove.
PS, forme u .netu nisu ekvivalent datamodula, ako hoces datamodul u .NETu onda se to radi rpeko Component-e, manji je overhead.

[att_img]


@shadowed: Tvoj pristup radi, moj komentar na celu ovu pricu je bio samo da je instanciranje celog forma samo i iskljucivo u svrhu dobijanja reference dataseta iz njega losa praksa.

Iskreno ne razumem ovo bas najbolje. Sta su datamoduli? Nisam radio u delphi tako da ne znam. Ova slika mi deluje nekako komplikovano. Kod mene je princip da imam jedan static DataSet koje sve forme vide, tako da mi nije potrebno nikakvo instanciranje formi da bi dosao do podataka.

Datamodul je u Delphiu bio ono sto je Component u .NETu, prosto kolekcija pod-komponenti vizuleno predstavljena kroz ikonice koje mozes kofigurisati kroz dizajner. Ovo sto vidis na slici su delphi ekvivalenti .NETovim konekcijama, komandama, adapterima i datasetovima (nije MS to izmislio ), ja sam samo zamazo imena onih koji nisu za javnost .
Sa tom razikom sto su datasetovi bili vezani za jedan entity (nisi mogao vise tabela u jedan dataset) pa ne postoje dijagrami za iste. Veoma veoma retko je postojalo vise od jedne instance modula i vecina delphi programera nastavlja sa istom praksom u NETu. To se vrlo brzo otme kontroli...

Znam, znam, tako i koristim

Nego u vezi onog tvog krmeta, isto tako mozes i u .net-u da napravis dataset sa toliko tabela i bice jos crnji i zamrseniji, jer su pored imena tabela jos vidljive i polja i sve ostalo, tako da nije u tom slucaju datamodul kriv... "Losa praksa" postoji u svakom programskom jeziku/alatu.

I jos nesto, kad smo vec tu. Zanima me kako je uopste MS zamislio da se koristi Dataset u VS-u, da li *celu* bazu tj. model baze staviti u jedan Dataset, ili napraviti za svaki "logicki entitet" u aplikaciji po jedan dataset, npr. SubjektDataset koji sadrzi glavnu tabelu Subjekti linkovanu na podtabele SubjektiTelefoni, SubjektiXYZ, ...?

Imas na par mesta njihove best-practices npr Best Practices for Using ADO.NET, ali ne ocekuj bas mnogo od toga Nista to nije zapisano u kamenu i kao sto rekoh radice, ali ako ti manager dozvoli da radis tako onda je los manager, jer ti ovime efektivno izazivas bespotrebne troskove u daljem odrzavanju i prosirenju softvera, kao sto ih ja sad kao eksterni resurs kostam za ispravljanje ovog krmeta u Delphiu. To je jedini problem, ne da nece raditi ili da MS to ne preporucuje.
Sto se mene licno tice, ja i moje kolege ovde forsiramo "use-case" approach, tj jedna dataset shema po use-case-u i nikakvi singletoni. To nam daje kotrnolu nad ulazom i izlazom podataka na nivou korisnickih operacija, a pride omogucava konkurentnost identicnih operacija u nizim layerima