Ako možeš da koristiš .NET driver bolje ti je da koristš njega nego ODBC. ODBC je univerzalno rešenje, koji je neki wrapper za sve baze, dok je konkretan driver za konkretnu bazu bolje rešenje.

Kao prvo Hvala na brzom odgovoru.

Posto sam josh "zelen" oko svega ovoga, trazio sam po forumu li ne mogu da nadjem odgovor na sledece pitanje:

koliko sam ja razumeo grubo receno - ukoliko koristim npr. NET Driver/Connector za razvoj aplikacije, dovoljno je da doticni *.dll ubacim u Bin folder pri upload-u aplikacije na server.

Da li treba da trazim host provider-a koji nudi podrsku za taj NET Driver/Connector ili je dovoljno gore navedeno?

Da odgovorim sam sebi:

Ne pije to vodu - ^^^^^^ gore navedeno

Aplikacija se kod nas pravi ocigledno prvo po uslovima hosting provajdera, zatim idu uslovi klijenta koji je narucio aplikaciju...cccccccccccc

jedan provajder podrzava NET, ostali samo ODBC, a stvarno mi nije jasno sto im je tesko da ubace jedan *.dllna server i voala!!!!!!!

frustraciji nikad kraja.

Danas sam prebacio kod sa SQL na NET, a sada to isto prebacujem na ODBC...cccc katastrofa.

I kod nas i u inostranstvu se pravi po uslovima hosting provajdera. Po tom pitanju postavljanja uslova se provajderi ne razlikuju ni u inostranstvu od "loshih nas". Standardna praksa ti je da u skladu sa potrebama odaberes provajdera. Naucio si jednu vaznu lekciju, a to je da se najvise isplati da razvojno okruzenje sto vise lici na deployment okruzenje.



Zasto si frustriran? Vidis da si za jedan dan prilagodio aplikaciju uslovima hostinga. Treba da budes veseo a ne frustriran. To sto ti se klijent isciganisao za jeftini shared hosting ili tako nesto nije problem provajdera, a ni tvoj.

Da li je potrebno da server ima instaliran MySQL.NET Connector da bi moja aplikacija radila ili je dovoljno da kopiram bin folder sa dll-ovima pa da to funkcionise?

Koja bi bil dostojna zamjena ovom konektoru za baratanje podacima?

I mene to zanima.




ODBC 3.51, vecinom zbog toga sto ga svi hosting provideri podrzavaju.

Uzeo sam dvije aspx stranice. Na jednoj sam stavio datagrid koji sam povezao sa ODBC drajverom i dao mu upit. Mjerio sam vrijeme koliko mu treba da prikaze podatke i to je u prosjeku oko 5 do 6 sekundi (baza ima 21000 redova i 20 kolona)

Na drugoj aspx strani sam uradio isto to preko MySQL.NET connectora i vrijeme za koje konektor popuni tabelu je dosta duze.

Takodje sam poslije toga uporedio i dvije vrste upita:
1. SELECT *,(SELECT naziv from tbkategorije
where id=djelatnost) as djelat from tbklijenti; - ovdje sifru djelatnosti mjenjam nazivom djelatnosti
2. SELECT *,tbkategorije.naziv from tbklijenti inner join tbkategorije
on tbkategorije.id=tbklijenti.djelatnost; - isto to samo sa naredbom JOIN

prosjecno vrijeme odziva 1 komande je 2.44 sek a 2 komande je 3.93 sto znaci da je JOIN sporiji od where upita. Prije ovoga sam mislio da je MySQL.NET brzi od ODBC.NET i da je upotreba JOIN brza od WHERE...

sta mislite o ovome?

Hm, ovo zadnje je baš zanimljivo. Da li je to možda karakteristično za MySQL?
Za vikend cu uraditi testove na MSSQL.

mozda je where brzi samo u slucajevima kada se spajaju dvije tabele. Mozda bi u slucaju vise tabela, JOIN ipak bio efikasniji.

U slucaju vise tabela mislim da je JOIN efikasniji u smislu pisanja samog upita i dosta je pregledniji (Bar meni).

Sto se tice izvrsavanja mislim da je where ipak brzi bez obzira na broj tabela.