I don’t think this merits a blanket statement like that. Perhaps ODBC is slow in your particular situation using Access as a backend, or with unoptimized queries.
My experience with using ODBC to connect to SQL Server (2k -2K8) backends from Xojo (and previously Access) has shown it to be more than adequately fast, very stable, and trouble free. These were multi-user apps (10-15), with 50-80 small to medium sized tables.
Also, and importantly for some, ODBC is cross-platform, while ADODB isn’t.
I agree with Tanner -
Just a silly little test here, but retrieving 5,502 rows of a table with 27 fields, ordering by an indexed field, in ODBC was 0.643 seconds. Using OCI calls, it was 0.527 seconds.
Both calls were made over the network to a machine that is running Oracle, on a single core of an i3 processor. In other words, no great shakes as a server.
Making the same call using ODBC to a PostGres database local on my development machine, to the same data actually, ran in 0.053 seconds. That’s not shabby performance for any system.
I suggest that whether ODBC is slow or not depends more on your situation and design than anything else. I suspect you could make that application much much faster if you were not shackled with restraints to use Access.
I don’t see any reason the ODBC API should be inherently slow either. I think perhaps it has that reputation because many database providers have implemented ODBC by creating a wrapper over their own client library which inevitably results in their ODBC driver being a little slower than using the library directly.
Tanner, Paul, Steve, I totally agree with you that ODBC could be faster if not constrainted to using Access, however Access databases was part of the original question. The suggestion was made to the customer of moving to SQLExpress or similar, but that was rejected.
Therefore in the context of linking to Access Databases, I beleive my answer that ODBC is slower than ADODB is correct.