Pa sad, razloga ima veoma mnogo ...
Da te obradujem, vecina korisnika kojima instaliramo vb.net aplikacije, se zali na usporenje racunara. jos je katastorfalnije na nekim PII i PIII masinama, sa 128 mb ram, ali mi se zalio i tip sa compaq-om na 2.6 GHz i 512 MB Ram.

Sto se tice crystala, on je uvek spor. Bez obzira koliko redova ubacujes u njega, treba mu izvesno vreme da se popuni.
Na crystalu imas mogucnosti da iskoristis njegove funkcije za sumiranje, pravljenje novih kolona izvedenih iz data kolona ... zbilja su ga obogatili sa tim opcijama. Nekoriscenje tih opcija ti moze malo da ubrza taj proces, ali koliko mi se cini, sve zvisi od slucaja do slucaja. Sto se tice podataka, na nekim izvestajima skoro da i nema razlike izmedju stampanja 3-4 reda i stampanja 500 redova.

Na ovu temu imas jos naslova u ovom forumu, pa prolistaj, ali osnovna cinjenica jeste da se svaka .net aplikacija izvrsava posredno preko frameworka, tj. svaka akcija u .net-u prvo poziva framework koji izvrsava daljnju akciju.
Prvi poziv aplikacije, traje malo duze jer treba da se aktivira framework.

Printanje moze da se ubrza prelaskom na PrintDocument object, ali to lagano vuce na razvoj vlastitog RPT Designera(izvdljivo).
Inace, Zasto koristis DataReader object za punjenje DataTable-a? Zasto ne koristisi DataAdapter?:
DataAdapter.SelectCommand.CommandText="select bla,bla"
DataAdapter.Fill(DataTable)
?

Ma koristim i jedno i drugo, testiram šta mi je brže. Teorija kaže da je DataReader mnogo brži, ali sama ne znam da li je to tačno.

Hvala mnogo na pomoći, jer moji korisnici kukaju, Access pa Access, pa Access je bio mnogo bolji.

Zato što je prvi put potrebno da se u memoriju prvo učitaju delovi .NET frameworka. Takođe potrebno je i da se tvoja aplikacija kompajlira. Kada sledeći put pokreneš svoju aplikaciju .NET je već u memoriji pa otpada onaj prvi deo.



Reci im da treba da podnesu svoj deo žrtve zarad sveopšteg dobra :)

Bas sam skoro skinuo sa neta (ubi me ako znam gde), klasu koja stampa dokument iz Dataseta ili DataTable-a, (ako sam dobro razumeo da tako nesto radish) i nisam imao problema sa brzinom. Pa, ako te interesuje (ili bilo koga drugog) javi se na mail pa da ti posaljem.

da, da datareader je brzi od dataadaptera

a koliko je isplativo i funkcionalno?

Uradio sam jedan u sklopu svoje aplikacije.Međutim zbog ograničene funkcionalnosti, (nema grupiranja) koristim ga samo za design POS izvještaja
(mada sam u startu zamislio sve izvještaje raditi u njemu)
i tu se isplati,jer za cas slozim izvjestaju za DOS printing preko CMD.exe-a (bez ikakvog drivera)
(zamisli da u velikom trgovačkom centru printaju racune pomocu CR-a).

Ukratko, u sljedećoj verziji planiram uvesti i to grupiranje,ali generalno,taj RPT designer mora imati sve glavne funkcije-bar kao access report da bi ga se stvarno i koristilo.. (vido sam jedan designer zasnovan na ovoj komponenti, mislim od Componnent One-a, i čini mi se da bi se dalo nešto tako napraviti)

Kod CR-a me osim sporosti jako,jako nervira nepostojanje 'remove horizontal spacing' opcije ,crkli dabogda.:-(: zatim, izmjena samo jednog polja u datatable-u učini da je .RPT neispravan, ali pazite, CR ne javlja koje je to polje, nego moraš sam odmozgati. Pa oni bug-ovi sa .XML om (datum,refresh itd.), 'set data souce location'. Svega tog nema kod vlastitog designera.

Inace , jako me muci ta sporost .Net-a, tako da sam povremeno razmisljao i o manged C++ i o prelasku na Oracle alate itd.itd...


Mene isto tako , kao i Jelenu , nervira što mi je prethodna aplikacija radila puno,puno brže.
(kad čovjek počne sumljati u rođenu aplikaciju to je vrlo tužno.)


Ima li kakvih nazanka o tom .Net chipu (pandan Java chipu)?

Hmm, pa dobro jeste cr spooooooooooor, ali ....

reci mi koliko ti je otprilike trebalo vremena za razvoj tog prvog dela?
mi smo planirali nesto slicno, ali .... vreme ...

ne vise od 7 dana..poslao bih screen shotove,ali ne znam koristiti ovaj [img](url?)[/img]

Nažalost, Managed C++ ti neće mnogo pomoći. I on prevodi kod u IL kao i C# ili VB.NET.

Meni se čini da ste previše rano krenuli sa .NET desktop aplikacijama. Bar dok ne stigne Longhorn, .NET-u je mesto na serverima, baš kao i Javi.

Pardoniram se mislio sam na unmanaged C++.
Inače, što se trača preko velike bare:
Da li ima naznaka pandanu-java chipu -.net cip-u i da li ce stvarno longhorn softverski riještiti ovu sporost ili ste mislili na to da cemo uz longhorn imati jače mašine?

Pa ni ti Java čipovi se u praksi nigde ne koriste. Čak je i Sun odustao od razvoja Java procesora. Što se .NET čipa tiče, čuo sam za neke priče na tu temu pre par godina, ali izgleda da je u pitanju samo trač.




I jedno i drugo, ali sam više imao u vidu softverska poboljšanja - .NET će biti sastavni deo OS-a i nadam se da će to unaprediti performanse, a možda i otkloniti potencijalnu zbrku oko raznih verzija frameworka.

Međutim, to je i dalje "svetla budućnost", a koje alate danas koristiti za poslovne desktop aplikacije, ostaje veliko pitanje. VB6 odlazi u prošlost i počinjati nešto ozbiljnije u njemu je suludo. C++ nije baš jezik za ovakve namene. Java je isto tako spora kao i .NET. Delphi?

grid tehnologija je nešto o čemo sam maštao prije 5 godina.i evo sad cujem da je izašao oracle 10 grid app server ...

Delphi je sa v8 prešao na .NET, što je i bilo očekivano. Čak je i ceo VCL prerađen u IL. Elem, kad sam video ASP.NET stranu u pascal-u video sam sve Da ne budem škrt, ako neko hoće da vidi kako izgleda code-behind jedne pascal asp.net strane, ima je u attachmentu. Ko ne veruje meni, nek veruje svojim očima.