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.