So what exactly is a database adapter? There is a company that wants to
provide reporting services to our customers using a proprietary technology,
but all they will tell us is they use an adapter and a listener through
ODBC. Seems to me that an adapter is just a fancy way of saying a wrapper
over ODBC and the listener must be installing some type of triggers or
something. I am psychotically opposed to any third party application
installing any objects into our databases. "Adapter" is a pretty darned
generic term and I'm not really comfortable with their explanation. I need
to be able to ask better questions.
Bob Castleman
DBA PoseurIt is possible that they have an ADO.NET DataAdapter. If so, it lives in
their application and not in your database. And yes, it's basically a
wrapper that encapsulates database-specific connection properties and
methods. But that's just a wild guess as to what *they* mean by "data
adapter".
-HTH
"Bob Castleman" <nomail@.here> wrote in message
news:eKI2vPRbFHA.2420@.TK2MSFTNGP15.phx.gbl...
> So what exactly is a database adapter? There is a company that wants to
> provide reporting services to our customers using a proprietary
> technology, but all they will tell us is they use an adapter and a
> listener through ODBC. Seems to me that an adapter is just a fancy way of
> saying a wrapper over ODBC and the listener must be installing some type
> of triggers or something. I am psychotically opposed to any third party
> application installing any objects into our databases. "Adapter" is a
> pretty darned generic term and I'm not really comfortable with their
> explanation. I need to be able to ask better questions.
> Bob Castleman
> DBA Poseur
>|||The adapter part seems obvious to me, but what is not at all clear is how
this can *sense* updates to the database without installing triggers.
Hmmmm.
Bob
"Jeffrey Todd" <Me@.Somewhere.net> wrote in message
news:OTpcBmRbFHA.2212@.TK2MSFTNGP14.phx.gbl...
> It is possible that they have an ADO.NET DataAdapter. If so, it lives in
> their application and not in your database. And yes, it's basically a
> wrapper that encapsulates database-specific connection properties and
> methods. But that's just a wild guess as to what *they* mean by "data
> adapter".
> -HTH
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:eKI2vPRbFHA.2420@.TK2MSFTNGP15.phx.gbl...
>|||<< not at all clear is how this can *sense* updates to the database >>
Maybe they use classes in the System.Voodoo namespace in conjunction with
their ADO.NET DataAdapter.
without knowing more, and grasping for possibilities, maybe they
periodically query the db and compare against values in the application's
memory or perhaps compare to values persisted to a local disk where the app
is running... but that gets ugly quickly if they're doing it that way.
Can you tell us more about what they plan to actually install, and where it
gets installed? This "listening" thing is puzzling. Are they installling a
Windows Service that will broadcast on some port that gets listened to? Are
they setting up some custom TCP Server?
-JT
"Bob Castleman" <nomail@.here> wrote in message
news:uZ5ml4RbFHA.720@.TK2MSFTNGP15.phx.gbl...
> The adapter part seems obvious to me, but what is not at all clear is how
> this can *sense* updates to the database without installing triggers.
> Hmmmm.
>
> Bob
> "Jeffrey Todd" <Me@.Somewhere.net> wrote in message
> news:OTpcBmRbFHA.2212@.TK2MSFTNGP14.phx.gbl...
>|||Well it turns out that after beating them upside the head they finally
admitting to using triggers. I have no clue why they were so freaking
secretive.
This brings up my next question. Would any DBA worth anything ever allow a
third party application to install triggers? In my mind, my database is
sacred and NOBODY outside of my organization can change it. Technically, a
trigger isn't a schema change, but I have real problems with somebody else
sticking objects in my databases.
Bob
"Jeffrey Todd" <Me@.Somewhere.net> wrote in message
news:OJbRvDTbFHA.3240@.TK2MSFTNGP12.phx.gbl...
> << not at all clear is how this can *sense* updates to the database >>
> Maybe they use classes in the System.Voodoo namespace in conjunction with
> their ADO.NET DataAdapter.
> without knowing more, and grasping for possibilities, maybe they
> periodically query the db and compare against values in the application's
> memory or perhaps compare to values persisted to a local disk where the
> app is running... but that gets ugly quickly if they're doing it that way.
> Can you tell us more about what they plan to actually install, and where
> it gets installed? This "listening" thing is puzzling. Are they
> installling a Windows Service that will broadcast on some port that gets
> listened to? Are they setting up some custom TCP Server?
> -JT
>
> "Bob Castleman" <nomail@.here> wrote in message
> news:uZ5ml4RbFHA.720@.TK2MSFTNGP15.phx.gbl...
>|||"Bob Castleman":
> Well it turns out that after beating them upside the head they finally
> admitting to using triggers. I have no clue why they were so freaking
> secretive.
> This brings up my next question. Would any DBA worth anything ever allow a
> third party application to install triggers? In my mind, my database is
> sacred and NOBODY outside of my organization can change it. Technically, a
> trigger isn't a schema change, but I have real problems with somebody else
> sticking objects in my databases.
> Bob
Personally, I wouldn't allow it: I don't like allowing in-house personnel to
add triggers :)
One thing: is this solution for auditing all database activity? If that's
what you're looking for, you can try Lumigent. I like their Log Explorer
product, but they also have a full-blown activity audit product called (I
think) Entegra: obviously it's a lot more expensive.
Their products are based on proprietary technology that examines the SQL
Server log files, so no triggers or any other schema change. (Log Explorer
does need it's own database, so I assume Integra does as well).
Craig|||It's just a reporting application. What bugs me is that we have an XML based
API but the refuse to use it.
The log explorers are something I've looked at briefly for auditing.
Especially in light of SOX, they might be useful. It could be a convenient
way to maintain audit trails.
Bob
"Craig Kelly" <cnkelly@.spamnomore.worldnet.att.net> wrote in message
news:z14qe.302594$cg1.243213@.bgtnsc04-news.ops.worldnet.att.net...
> "Bob Castleman":
>
> Personally, I wouldn't allow it: I don't like allowing in-house personnel
> to add triggers :)
> One thing: is this solution for auditing all database activity? If that's
> what you're looking for, you can try Lumigent. I like their Log Explorer
> product, but they also have a full-blown activity audit product called (I
> think) Entegra: obviously it's a lot more expensive.
> Their products are based on proprietary technology that examines the SQL
> Server log files, so no triggers or any other schema change. (Log
> Explorer does need it's own database, so I assume Integra does as well).
> Craig
>
