Any Real System Guy worth their salt would know how to set up an account
for you to use for SQL queries like these with read-only rights and low
processing priority/throttling so there would be little to no chance of
it affecting system performance.  Even if they don't know, they could
find out all they need to know with about 5 minutes of hax0ring the
G00G13... or going to the library and getting an Oracle systems
administration for dummies book if they're not into the whole internet
thing.

So it sounds to me like they're stonewalling you because they flat out
don't know what they're doing and don't care to find out.  In which
cases, condolences.



On 1/17/07, Nathan Vack <[log in to unmask]> wrote:
> On Jan 17, 2007, at 2:59 PM, Bess Sadler wrote:
>
> > As long as we're on the subject, does anyone want to share
strategies
> > for syncing circulation data? It sounds like we're all talking
about
> > the parallel systems á la NCSU's Endeca system, which I think is a
> > great idea. It's the circ data that keeps nagging at me, though.
Is
> > there an elegant way to use your fancy new faceted browser to
search
> > against circ data w/out re-dumping the whole thing every night?
>
> Sure isn't elegant, but as our Real Systems Guys don't want us to
> look at the production Oracle instance (performance worries), we've
> had pretty good luck screen-scraping holdings and status data, once
> we get a Bib ID. Ugly, but functional, and surprisingly fast.
>
> Of course, spamming the OPAC with HTTP calls certainly impacts
> performance more than just querying the database... but I digress.
>
> In a perfect world, we'd get a trigger / stored proc on the database
> server when circ status changed. In a slightly less perfect world,
> I'd just keep a connection open to the production datbase server for
> all of that.
>
> -n
>
>