Since the inception of ODBC (circa. late 1992) there have been two prime barriers to its total comprehension:

  • Misconception that it's inherently slow (a message originating from it's creator's, not Microsoft, but rather, the collection of DBMS vendor companies that actually created the SAG CLI from which ODBC was derived)
  • ODBC Drivers are valueless (or at best a check in the box item) so bottom line they cost nothing and we (the DBMS vendors) shall offer them to you free of charge.

The performance issues arenbspnow long forgotten (at least as far as OpenLink Software's contribution to ODBC goes). But the ODBC Drivers must be FREE as they offer little or no value problem rages on.

The Usenet posting below pretty much sums up why I decided that OpenLink needednbspto get into the ODBC Driver business in the first place. We anticipated significant problems in the area of usability, configurability and security if all a driver had to offer was query fulfillment in the form of a result set.

The excerpt below shows an all too common dilemma with ODBC (should you reach rollout and put ODBC in the hands of information and knowledge workers):

nbspHi all,

I set up an Excel spreadsheet to our production database through ODBC driver to get a report. Everything was working fine, and life was good until I found a little problem with the SQL tool in Excel.

Normally, to get a report Excel will write a select statement according to criterias that the users input/ choose. It also allows anyone to Edit the select statement it writes in a little box. What I did was changing that select statement to delete/update statement. And it ran.

What surprised me was that it actually ran the statement against the database and delete/update tables accordingly. This is not what we want. I have not been able to find any options to turn this thing off so that the user cannot edit the generated select SQL.

I know all the permissions the user has are defined through the username that is defined in ODBC. We don't want to change all the user permissions on the database side. Is there any other way ? MS Excel 2000 Informix IDS 9.30 UC1 Dynix/ptx V4.5.3 Thanks N.

The user's ODBC usage requirements are unconventional to a database engine. What do I mean? Well relational databases fundamentally handle security on a user or role basis, and this security schemes can be applied to tables and rows, but it does nothing for this scenario.

The ODBC Drivers from OpenLink Software were built (in 1993 I might add)nbspwith thisnbspmiddleware predicamentnbspand more in mind. As you might imagine, most ODBC vendors will tell you to sort out the security either at thenbspdatabase end or the client application end.nbsp

OurnbspDrivers (the Multi-Tier variant) on the other hand enable you to configure a set of rules that will enforce read-only access on an application basis such that in this particular case when Excel is used the session is read-only irrespective of what exits MS Query. The rules can even enable read-write or read-only access to Excel (or other ODBC compliant application) and the basis of any combination of the following: username, client ip, machine alias, application, lan subnet, and any user definable profile (we call these domains).

Additional reading as this is only the tip of the iceberg.