ODBC je jeste sporiji, ali doar prilikom razvoja ASP ili DT aplikacije, jer sve gresko koje se desavaju u SQL-u pisu punim opisom i brojem linije, za razliku od malo brzeg OLE DB koji je znatno brzi i nije lose preci na njega kada se razvije citava aplikacija i kada je sve spremno za malo brzi rad :) Ja mislim da je tako a voleo bih dacujem i duge, jer i mene ovo interesuje!

Isključivo ADO komponente!!!
I zbog portabilnosti i performansi. Sve ostalo je samo nepotrebno zaobilaženje i komplikovanje. Tu koristiš ADOQuery, ADOTable ili ADODataSet (koji obuhvata oba). Ako imaš više tabela i upita najbolje je da definišeš ADOConnection na bazu pa ostale DataSet-ove da povezuješ preko nje, a ne direktno. Pri kreiranju ConnectionString-a razlikuju se provajderi za Access i SQL server.

Da li se u necemu bitno razlikuje koriscenje ADOQuery i ADODataSet komponente od standardne TQuery i TDataSet komponente koje sam do sada iskljucivo koristio ?

Imas li podatak koliko je brze procentualno koriscenje ADO pristupa od ODBC-a i da li imate iskustva sa DBISAM bazom podataka i da li je on brzi od Access-a ili eventualno neki savet sta koristiti drugo ako ne Access ? (podrazumeva se za neke male programe/projekte).

Hvala unapred.

TADODataSet je izveden iz TDataSet tako da nad njim možeš da radiš sve ono što i nad TDataSet (i još nešto preko). Ako se radi o zaista maloj aplikaciji i ukoliko je isključivo za Windows, Access je sasvim zadovoljavajući. Jasno, ovo nije server baze tako da ukoliko veći broj korisnika radi nad bazom treba koristiti nešto drugo. Možda ne baš Oracle ili MS SQL Server, ali recimo Borland Interbase, MySQL...

"Najlepša" prednost TADO... komponenti jeste to što im ne treba BDE, već samo instalirane Microsoft Data Access Components (MDAC).

Nedostatak je sto aplikacije sa ADO komponentama ne rade na starijem OS-u od Windows 98.

Apsolutno se slažem sa pristupom koji je naveo Ruka: TADOConnection, TADODataset ...

Naravno, većina mogućnosti zavisi od provajdera!