SQL Server 2000-2005 upgrade i dijagrami

Importovao sam bazu sa SQLServer-a 2000 na SQLServer 2005 i suočio se sa nemogućnošću da vidim/editujem dijagrame. Poruka je "Database diagram support objects cannot be installed because this database does not have a valid owner...". Promena vlasnika baze nije pomogla. Rešenje koje je meni pomoglo je na http://www.sql-server-performance.com/forum/topic.asp?TOPIC_ID=10946

In SQL Server Management Studio do the following:

1. Right Click on your database, choose properties
2. Goto the Options Page
3. In the Dropdown at right labeled "Compatibility Level" choose "SQL Server 2005(90)"
4. Goto the Files Page
5. Enter "sa" in the owner textbox.
6. Hit OK

Druga varijanta (koju nisam probao) je:

EXEC sp_dbcmptlevel 'yourDB', '90'
go
ALTER AUTHORIZATION ON DATABASE::yourDB TO "yourLogin"
go
use [yourDB]
go
EXECUTE AS USER = N'dbo' REVERT
go

Računari i korišćenje naših slova

Danas, kada je prošlo skoro 10 godina od kada je korišćenje znakova iz raznih alfabeta u dokumentima koji se pamte u elektronskom obliku i razmenjuju preko Interneta rešeno na globalnom nivou i teorijski i praktično u Srbiji se idelje diskutuje na tu temu i veliki broj korisnika računara, pa i profesionalaca, ne zna da koristi naša slova tako da svima budu vidljiva, ili, što je možda i gore, izbegava da koristi naša slova. Tako treba dobro promisliti da li je „kuce“ zapravo kuče, ili su u pitanju kuće ili ipak kuce u smislu mali kučići. Ako spadate u ovu kategoriju korisnika a teorijska priča i hronologija ovog problema vas ne interesuje, idite pravo na kraj teksta gde su preporuke šta vam je činiti. U suprotnom, čitajte redom...

Jedan od najstarijih oblika elektronskog zapisa teksta je ASCII standard. Prvobitno je za zapis znakova koristio 7 bitova, što je davalo mogućnost za kodiranje ukupno 128 znakova. U tih 128 znakova spadaju slova engleskog alfabeta, brojevi, znakovi interpunkcije i slično. Kasnije je broj bitova koje ASCII koristi za kodiranje jednog znaka povaćan na 8 (jedan bajt), i to je tzv. prošireni ASCII u kome postoji prostor za još 128 znakova. To je prvi standard koji se koristio u PC eri. Inicijalno, tih dodatnih 128 znakova se koristilo za grafičke simbole za crtanje linija, uglova prozora i slično (za svakog DOS programera čuveni znakovi poput ╣╦╔). Istovremeno, tih 128 dodatnih znakova se koristilo i na druge načine, najčešće da se kodiraju znakovi nacionalnih alfabeta koji ne postoje u engleskom alfabetu. Tako su, na osnovu raznih interpretacija „gornjih“ 128 kodova, nastale čuvene kodne strane. Za naše potrebe Microsoft je definisao kodnu stranu 852 u kojoj razni kodovi od 129-255 označavaju naša slova.

Ali pošto smo mi u fazonu „neće nama neko da diktira standarde“ kod nas se odomaćio potpuno lokalni, nigde priznati nestadard zvan YUSCII koji je „gurnuo“ naša slova u prvih, „donjih“ 128 kodova i to preko nikom, jel, potrebnih znakova kao što su {, }, \ i slično. Primena je bila harrrrrddd/porno – YUSCII je zakivan u EPROM-e (tada aktuelnih) Hercules video kartica i matričnih štampača, dletom i čekićem graviran na tastaturama umesto bespotrebnih izgnanih karaktera... Prva fatalna posledica je bila da je su programeri, kojima su izbačeni znakovi bili potrebni zbog sintakse jezika u kojima su programirali, naša slova omrznuli za mnogaja ljeta, pa i dan danas mnogi kupuju engleske tastature umesto onih sa našim slovima „zato što im računar treba za programiranje“. Druga je bila vizuelna tortura koju trpimo do dan danas –YUSCII je u windows eri implementiran pomoću posebnih fontova, pa YUSCII znakovi, ili nestanu ili grozno izgledaju kad se provuku kroz DTP alate.
Ko nam je „podmetnuo“ YUSCII, o tome se mogu naći razne teorije na Internetu, slične onima na temu ko je Srbima podmetnuo boljševizam. U jednom trenutku to je delovalo kao dobra ideja, ali se istorijski, kao i gore pomenuti boljševizam, pokazala fatalna za dragi nam narod kome pripadamo.

Konfuzija je pojačana sa pojavom Windowsa 95 u kome je podrška za kodnu stranu 852 i neke druge East-Europian kodne strane zamenjena jedinstvenom kodnom stranom 1250 (latinica) odnosno 1251 (ćirilica). U skladu sa našim ustavnim opredeljenjima za srpska regionalna podešavanja prirodan izbor je bila ćirilica. Uz ispravnu instalaciju i izbor kodne strane, naša slova su bila vidljiva u svim standardnim fontovima (Arial, Times New Roman...) ali je ljubav ka YUSCII kvazistandardu i YuTrtmrt.tft fontovima preovladala pa su se odmah pojavile razne zakrpe koje su omogućavale korišćennje YUSCII, a ponekad i 852 kodnog rasporeda na Windows-u (svaka čast momcima koji su ih zakrpe pravili, bili su vođeni zahtevima tržišta... mada se isto može reći za Pink TV recimo). Kao šlag na torti pojavljuje se (sa jedno 10 godina zakašnjenja) i organizacija koja je zadužena za standarde, ISO, i donosi svoj standard za kodiranje slova iz istočnoevropskih apfabeta, ISO8859-2, koji je taman toliko različit od Microsoft CP1250 da zagorča život. Tako smo pre 10 godina već imali potpuni haos – YUSCII, 852 i 1250 kodne strane, plus ISO8859-2, plus razna „home made“ rešenja pa sve to puta 2 kad se u obzir uzme i ćirilica. Veselju nije bilo kraja kad na Windows-u koji podržava CP1250 korisnik hoće da koristi YUSCII a da dokument odštampa na svom matričnom štampaču koji ima 852 kodnu stranicu ugrađenu u EPROM. Frustracije iz tog perioda mnoge nisu napustile do danas, pa beže od korišćenja naših slova ko đavo od krsta.

Rešenje iz ove konfuzije nije nađeno specijalno za Srbe, već za ceo svet i zove se Unicode. Do Unicode standarda nisu doveli (specifično srpski) problemi koje sam opisao, već potreba da se u jednom tekstu slobodno mešaju znakovi koji su do tada pripadali raznim kodnim stranama (zapravo raznim jezicima i pismima). Sporedna, ali za nas veoma važna posledica primene Unicode standarda je da je tekst sa našim slovima čitljiv na svim operativnim sistemima i u svim programima koji taj standard podržavaju. A to su, danas se slobodno može reći, praktično svi programi. Nije bilo lako anglosaksoncima da prihvate Unicode. Jasno je da jedan bajt više nije dovoljan da bi se zapamtio jedan znak i da će dokument koji je kodiran po Unicode standardu biti mnogo duži (u bajtovima) nego dokument kodiran ASCII-jem ili nekim drugim 8-bitnim kodom. To znači više prostora na memorijskim medijima i duže poruke koje se šalju komunikacionim kanalima (Internet). Jednom rečju, koštaće para. Međutim, potrebe globalizacije zahtevale su da se „proguta knedla“ i zapadni svet je prešao na Unicode. Postoji više varijanti implemantacije Unicode standarda koje imaju za cilj da uz zadržavanje podrške za razne alfabete optimizuju (minimizuju) dužinu tekstualnog dokumenta. Za latinične tekstove optimalan i svuda podržan je UTF-8 standard.

Unicode je u svetu široko prihvaćen. Od Windowsa 2000/XP, Unicode je prirodni način za kodiranje teksta u Microsoft operativnim sistemima. Podržan je u sistemima za upravljanje bazama podataka, Office paketu itd. Za razliku od zapadnog sveta, mi, koji imamo direktnu korist od primene Unicode jako smo spori u njegovom prihvatanju iako, realno, za to nema razloga. Jednostavno, Unicode je standard prihvaćen u celom svetu, nezavistan od platforme, i nema indicija da će ga nešto drugo zameniti u skorije vreme. Zato svi u Srbiji treba da se okanu ćorava posla i pređu na Unicode ako već nisu.

Praktične preporuke (uglavnom vezane za rad u Windows okruženju):
Izbrišite sa svog računara sve fontove koji počinju sa YU. Ukoliko vam bude potrebno da koristite neke stare dokumente, pisane po YUSCII , 852 ili sličnim standardima, iskoristite neki od besplatno dostupnih konvertora da stare dokumente prebacite u Unicode/UTF-8. Ja lično koristim VIA konvrtor.
Kupite YU tastaturu ako je nemate. Ignorišite eventualne sugestije prodavca da uzmete englesku. Ili su neobavešteni, ili na engleskim tastaturama koje se prave u većim serijama imaju veću profitnu marginu.
Podesite operativni sistem za na Serbian/Latin kombinaciju.
U e-mail porukama koristite za encoding auto-select ili UTF-8 encoding. Svi će videti naša slova u vašim porukama, bez obzira kakvu tastaturu ili regionalno podešavanje imaju. Jedini izuzetak može da bude Subject poruke ili vaše ime – pojedine „kapije“ kroz koje vaš mail treba da prođe do odredišta mogu da pojedu naša slova u poljima zaglavlja.
Word dokumente pišite korišćenjem naših slova i standardnih fontova. Ceo svet će moći da ih pročita...dobro, bar onaj deo koji je prevazišao Windows 95.
Internet stranice postavljajte sa našim slovima po Unicode/UTF-8 standardu. Ako ručno editujete stranice, u zaglavlju HTML strane treba da piše: meta equiv="Content-Type" content="text/html; charset=utf-8". Tako će ceo svet moći da vidi u njima naša slova.

Kako kroz ASP.Net prikazati slike iz Access baze?

Access pamti OLE objekte a ne slike u bazi pa svaka slika ima dodatni OLE header, koji je dužine 78bajtova (uvek?). Tih 78 bajtova treba skinuti da bi se dobila čista slika. Dalje, Access pamti slike u bmp formatu koji je prevelik za Internet. Zato je poželjno izvršiti konverziju, recimo u jpeg. Evo primera za ASP.Net 2.0. Predpostavka je da Select metod ObjectDataSource1 objekta vraća jedan slog u kome se nalazi polje "slika".

DataView dv = (DataView)ObjectDataSource1.Select();
byte[] b = (byte[])dv[0]["slika"];
MemoryStream ms = new MemoryStream(b, 78, b.Length - 78);
Image i = new Bitmap(ms);
Response.ContentType = "image/jpeg";
i.Save(Response.OutputStream, System.Drawing.Imaging.ImageFormat.Jpeg);
Response.End();

ADO.NET 2.0 TableAdapter

Kad softveraš prelazi iz VS2003/.Net1.1 u VS2005/.Net2.0 okruženje lako odođe u iskušenje da jednostavno konveruje svoje aplikacije koje barataju bazama podataka. Objektni model ADO.Net 2.0 nije mnogo drugačiji od onog u 1.1 verziji. I dalje osnovu čini tandem Dataset i DataAdapter klasa. Međutim u VS2005 okruženju glavnu ulogu preuzima TableAdapter. TableAdapter-i nisu deo framework-a, već se radi o klasama koje generiše VS dizajner (najčešće novi Data Source Confiration Wizard), koje za programera enkapsuliraju rad sa DataAdapter i Connection objektima i koje su intenzivno podržane od vizuelnih alata u VS2005. Velika je stvar što TableAdapter podržava proizvoljan broj select upita (za razliku od DataAdaptera koji podržava jedan select upit) pri čemu wizard za svaki upit generiše metode koji pune/kreiraju Dataset za programera. Na primer, programer sada koristi jedan isti TableAdapter MyTableAdapter da bi dobio spisak artikala, artikle koji pripadaju jednoj grupi ili pojednični artikal ili tako što poziva metode MyTableAdapter.GetProducts(), MyTableAdapter.GetProductsByCategory(string category), MyTableAdapter.GetProductsById(int id).
Iz mog dosadašnjeg iskustva u radu sa TableAdapter-ima mislim da je pri prelasku na VS2005 bolje od početka napisati deo aplikacije koji komunicira sa bazama podataka i iskoristi prednosti koje nudi VS2005 (pored TableAdapter-a tu su i Data Sources i druge džidža midže) nego prosto konvertovati VS2003 projekat.

C# - OR i AND operatori

C# ima dva OR logička operatora: I i II . Razlika je što se kod II drugi operand izarčunava samo u slučaju potrebe tj. ako je prvi false. Vrlo zgodno za testove tipa:

x==null II mySting.Contains(x)

Za x=null gornji izraz bi pao korišćenjem operatora I ali sasvim lepo radi sa II. Ovo je zbunjujuće za C++ programere kod kojh je I bitwise a II logičko ili. Slično važi i za AND operatore, & i &&

Neke ASP.Net 2.0 serverske kontrole su teške kao tuč

Pričam o broju bajtova koje dodaju web stranici kroz klijentske skripte na kojima se zasnivaju. I dok su za intranet i širokopojasni Internet ASP.Net 2.0 kontrole zaista ogroman korak napred praktično su neupotrebljeve za upotrebu preko dial-up ili čak i ISDN linkova. Tipično - strana koja sadrži (recimo) ASP.Net 2.0 Login kontrolu učitavaće se 5-6 sekundi na 64K linku i samo sekundu-dve ako programer sam ubaci na stranu text box-ove za username i password, button za potvrdu i kod u pozadini koji korišćenjem Membership klase radi ono što radi i Login kontrola. A to je za korisnika ogromna razlika koja može da bude presudna u odluci da li će neki web site uopšte da koristi. Rezon Microsoft-a je da se jscript kod dodaje dodaje u dll fazonu, tj. ako ti treba neka ASP.Net kontrola automatski se uz stranicu dodaje jscript biblioteka sa još mnogo funkcija koje su grupisane zajedno sa onom koja ti treba. Zapravo, ne moraš da dodaš neku novu ASP.Net 2.0 kontrolu da bi neprijatno nabildovao svoju stranicu. Dovoljno je, na primer, da staviš da je neki TextBox AutoPostBack i već si dodao jedno 15tak kila na svoju stranicu. To debljanje se teško primećuje dok radiš razvoj u lokalu, u intranet okruženju. Čak (perfidno!) ni veličina strance se direktno ne poveća, zato što se jscript dodaje kroz dinamički generisane eksterne fajlove na koje ASP.Net u glavnu stranu samo ubaci link. Zaključak: ako planiraš da aplikacija radi i preko sporijih linkova, izbegavaj korišćenje naprednih ASP.Net 2.0 kontrola na stranicama koje se najčišće koriste.

GridView ASP.Net 2.0 kontrola i novi slogovi

Toliko toga odrade čarobnjaci u VS2005... Ali da bi dodao novi slog iz GridView kontrole treba dobro da riljaš. Ima na netu raznih rešenja: http://www.codeproject.com/aspnet/addupdate.asp predlaže modifikaciju select komande u DataSource tako da bude union jednog praznog sloga i polaznog select upita i onda se (dodatnim mrčkanjem) taj prazan slog koristi kao podloga za novi. Ne deluje baš elegantno. Ja još od 1.1 verzije koristim footer kao prostor za kontrole u koje se unose podaci za novi slog. Prednost u odnosu na prvo rešenje je što je "prazan slog" (kod mene u footeru) vidljiv samo ako korisnik klikne "add new" dugme, a ne stalno. Mada ima i rešenja koja proveravaju event koji formatira item pa ne prikažu taj virtuelni slog. Vidim da nešto slično koristi i http://aspnet.4guysfromrolla.com/articles/021203-1.aspx. Ipak, ni ovo rešenje se baš ne ubija od elegnacije pošto moraš ručno da odradiš mapiranje parametara iz footera u insert parametre.

Google servisi

Čitam članak o Google-u u engleskom PCPlus časopisu, i zaista sam iznenađen brojem i kvalitetom Google servisa. Bogami, drmaju Microsoft dominaciju u IT svetu i to na pravi način - otkrivajući prvi nove terene na koje se IT primena seli.