Citat:
1.) Kako izbjeći da korisnici kada iz programa povlače report ne dobivaju upit za novi login na report server.
To je ona stvar sa CARDINALINA i SQL loginima. Ja kada na DATA SOURCE-u kažem da ne koristi cardinale on se onda na sql pokušava zakačiti Windows Autentifikacijom
Da li se sam report server portal može naštimati da ne traži cardinale ili se oni moraju svaki put proslijeđivati.
pogledaj tvoj Report rds fajl u kome si podesio parametre za bazu (connection string) i credentials .
Citat:
2.) Kakvo je vaše iskustvo sa Report Serverom kada se isti koristi kroz WEB komponentu kao report alatom. Isplati li se ulagati vrijeme u to.
Pa sve zavisi od realnih potreba ..
Nisam ga nikad koristio kao web-komponentu , vec samo generisem izvestaj koji mi report service
vrati kao excel pdf , ili html i dobijem nazad (download) kao fajl koji posle otvorim sa odgovarajucim programom .
pa nek korisnik stampa edituje ili sta vec iz tog programa .
Po meni ovo je mnogo jeftinije resenje nego embedovanje reporta u aplikaciju .
Citat:
4.) Gdije bi mogao uključiti dugme BACK u report tool baru.
Kada radim report u visual studio Report Preeview ima BACK dugme ako se radi o linkanim reportima.
Kada isti report pošaljem na server i pregledam ga kroz IE u report tool bar-u nemam dugmeta back.
Sada imam problem kada otvorim linkani report kroz svoju IE komponentu ne nemam ie dugme BACK a sam tool bar nema isto.
Jedini način da se vratim nazad je dugme BACKSPACE ali sa ovolikim brojem korisnika to je teško prenjeti svima.
pogledaj ovde za setovanje opcija u sekciji Report Viewer Web Part Commands
http://msdn.microsoft.com/en-us/library/ms152835.aspx
Citat:
5.) Na koji način ću naj elegantnije riještiti problem datuma kod parametara. Problem je u tome da Ie uzima neke svoje postavke datuma kako mu se zaželi.
Ja sam na report propertisima stavljao i Bosnian i Croatian i Austrian ali nisam dobvio neke ekstra rezltate. Jer opet bi on uzimao postavke datuma onakve
kakave su propisane u IE a ne kroz sam report.
Postoji li šansa da se samo polje parametra MASKIRA na DD-MM-YYYY pa makar on i proslijeđivao string nazad u report ja cu ga parsirati i praviti datum od istog.
Nemas potrebe za tim setovanje regional setingsa za datum .
Sve sto treba da uradis je da kad napravis polje u dizajneru koje treba
da sadrzi datum uradis sledece kad odes na Field expression:
Code:
=Format(Fields!TvojDatumIzBaze,"dd-MM-yyyy")
ilii da konvertujes datum kroz TSQL sa funkcijom CONVERT
Citat:
7.) I još jedno pitanje: Kakav je trend sada sa takozvanim THIN (web browser) klijentima da li se to razvija.
Da li je suludo pokušavati praviti forme za unos podataka u baze kod trgovački kuča koristeći ASP.NET i da li je to pogrešan smijer.
Jer sada kada imam WEB komponentu u samom programu pomišljam zašto ne bi i uradio pojedine forme za unos tamo gidje mi zafali podtaka.
Nisam se sretao sa knjigovostvenim programima koji rade na WEB vezi da li je to sporo previše ektai da se svaki put osvježi stranica i ostalo.
Isplati li se ići u tom smijeu.
Pa uopsteno govoreci postoji trend da se neke poslovne aplikacije sele na web (asp/php) .
Zadnjih par aplikacija koje sam radio po narudzbini klijenata zahtevano je da budu u web-browseru .
U principu sve zavisi od konkretnih klijentskih zahteva i samog projekta .
Desktop programi su mnogo funkcionalniji od web- aplikacija
ali korisnicima je izgleda lakse da barataju sa web-stranama nego sa desktop formama
i odrzavanje web aplikacija je mnogo lakse usled stalnih izmena jer im je mesto centralizovano (web-server) .
umesto desktop koji zahtevaju stalno novu instalaciju kad je u pitanju nova verzija .
Ovo dosta zavisi od arhitekture mreze i administriranja i security polisa
u firmi za koji razvijas program i naravno broj korisnika koji koristi aplikaciju .
Sto se tice osvezavanja stranica ne bi trebalo da bude toliko sporo pogotovu ako radi u LAN okruzenju ,
pa cak i da nije ..propusni opseg internet linkova se svaki dan povecava, tako da mislim
da nemas puno razloga za brigu .