ruby-dbi-devel — ruby-dbi development list

Re: [Ruby-DBI-devel] Rows Affected and Postgres

[Zakaria <z4...@bi...>]

Hi,

Sorry for jumping in but I also bitten by this problem.

I think the problem is an architechtural problem.
There at least 3 solution for this problem
1. Analyze the Query to check whether this a Select or Non-Select
   This is a big NO NO, because I don't want my database interface
   to be "smarter" then me and I think this is quite difficult
   to made if we consider stored procedure call.

2. Add DBI::StatementHandle#num_rows
   While this is easy, but this make the API less elegant because
   it force the programmer to remember two different method
   for the same operation (number of rows processed).

3. Add special method for DML Query (insert, update, delete)
   so we can reliably separate Select and Non-Select query.
   This is reasonable because you can't use row fetching method
   on DBI::DatabaseHandle#execute('UPDATE something...') result.

   Also this separation also occur in AOLServer Database API
   where they have ns_db select and ns_db dml.

So, what do you think about this?
Any other solution?

On Jum, 2002-04-19 at 05:25, Gabriel Emerson wrote:
> I should have said; it is in the postgres dbd.  Most databases return
> the affected rows and row counts in one call.  Postgresql uses two
> calls to do this.
> 
> I have patched my copy of postgres.  I sent a patch to the
> Ruby-Postgresql maintainer as well, which supports the change to the
> Pg.rb in DBI (it is in the latest version on the Ruby-Postgresql site.)
> What I did was create another function just like rows
> called "rows.affected", which returns @pgresult.cmdtuples instead of
> num_tuples.
> 
> I couldn't think of an easy way to make rows() return either value
> depending without analyzing the query... maybe it is simple.
> 
> Thanks,
>   Gabriel
> 
> (btw, I sent a similar patch to the SQLrelay maintainers, so the
> postgresql driver there returns either rows or affected rows, so the DBI
> interface to SQLRelay for Postgres should be correct)
> 
> 
> On Thu, 18 Apr 2002, Sean Chittenden wrote:
> 
> > > Has any decision been reached on whether to include the affected
> > > rows count in rows(), or if a new method will be created for the
> > > purpose?
> > >
> > > It's the last feature that keeps me from using a stock dbi on our
> > > system.
> >
> > I think that's a function of the underlying DBD.  What database are
> > you using?  I might be able to toss you a patch if it's postgres...  -sc
> >
> > --
> > Sean Chittenden


Regards,


-- Zakaria                         
Private: z4...@bi...     Yahoo!: z4k4ri4
   http://pemula.linux.or.id

Re: [Ruby-DBI-devel] Rows Affected and Postgres

[Gabriel E. <ga...@de...>]

I should have said; it is in the postgres dbd.  Most databases return
the affected rows and row counts in one call.  Postgresql uses two
calls to do this.

I have patched my copy of postgres.  I sent a patch to the
Ruby-Postgresql maintainer as well, which supports the change to the
Pg.rb in DBI (it is in the latest version on the Ruby-Postgresql site.)
What I did was create another function just like rows
called "rows.affected", which returns @pgresult.cmdtuples instead of
num_tuples.

I couldn't think of an easy way to make rows() return either value
depending without analyzing the query... maybe it is simple.

Thanks,
  Gabriel

(btw, I sent a similar patch to the SQLrelay maintainers, so the
postgresql driver there returns either rows or affected rows, so the DBI
interface to SQLRelay for Postgres should be correct)


On Thu, 18 Apr 2002, Sean Chittenden wrote:

> > Has any decision been reached on whether to include the affected
> > rows count in rows(), or if a new method will be created for the
> > purpose?
> >
> > It's the last feature that keeps me from using a stock dbi on our
> > system.
>
> I think that's a function of the underlying DBD.  What database are
> you using?  I might be able to toss you a patch if it's postgres...  -sc
>
> --
> Sean Chittenden
>

Re: [Ruby-DBI-devel] Rows Affected and Postgres

[Sean C. <se...@ch...>]

> Has any decision been reached on whether to include the affected
> rows count in rows(), or if a new method will be created for the
> purpose?
> 
> It's the last feature that keeps me from using a stock dbi on our
> system.

I think that's a function of the underlying DBD.  What database are
you using?  I might be able to toss you a patch if it's postgres...  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Re: Performance problems with dbd_pg

[Sean C. <se...@ch...>]

> Quick preliminary tests show that we have gone from 1000 x slower
> than Ruby-Postgres to about 5 times slower.
> 
> In short, you rock.

When's a new version coming out?  I may want to stick that patch into
FreeBSD's port if the new version is coming soon...  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Rows Affected and Postgres

[Gabriel E. <ga...@de...>]

Has any decision been reached on whether to include the affected rows
count in rows(), or if a new method will be created for the purpose?

It's the last feature that keeps me from using a stock dbi on our
system.

Thanks,

  Gabriel

(p.s. ruby-dbi is, if I may be so bold, the bomb)

[Ruby-DBI-devel] re: Performance problems with dbd_pg

[Gabriel E. <ga...@de...>]

Quick preliminary tests show that we have gone from 1000 x slower than
Ruby-Postgres to about 5 times slower.

In short, you rock.

--Gabriel

[Ruby-DBI-devel] Performance problems with dbd_pg

[James F. H. <jf...@ci...>]

I noticed in the archives that others had reported the performance problem
with dbd_pg. 

It turns out the problem lies in the repeated calling of PGResult#result
by fetchrow. PGResult#result creates the result array each time it's called.
The following patch takes care of the problem in DBD::Pg by caching the
result array, though it may be better to have the postgres driver cache 
the result array after the first call instead.

*** Pg.rb       Sun Dec  2 12:23:59 2001
--- /local/lib/ruby/site_ruby/1.7/DBD/Pg/Pg.rb  Tue Apr 16 23:07:17 2002
***************
*** 452,457 ****
--- 452,458 ----
          @db = db
          @pg_result = pg_result
          @index = -1
+         @result = @pg_result.result
          @row = Array.new
        end
  
***************
*** 461,468 ****
  
        def fetchrow
          @index += 1
!         if @index < @pg_result.result.size 
!           fill_array(@pg_result.result[@index])
          else
            @row = nil
          end
--- 462,469 ----
  
        def fetchrow
          @index += 1
!         if @index < @result.size 
!           fill_array(@result[@index])
          else
            @row = nil
          end

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jf...@ci...                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------

Re: [Ruby-DBI-devel] PostgreSQL data interpretation problems...

[Sean C. <se...@ch...>]

> So after digging through trace output and after diving through as many
> lines of SQL logs, I found what could be a nasty date parsing problem
> that could be biting folks here as well and want to give everyone a
> heads up.  The following code will demonstrate the problem:
>=20
> # CREATE TABLE timestamp_test (
>   utc_timestamp TIMESTAMP NOT NULL
> );
>=20
> # INSERT INTO timestamp_tmp VALUES ('2002-4-7 2:0:0.0');

Daylight savings boundary conditions.  blah.  This problem happened
because mktime() failed on FreeBSD in this time area because 2am is
actually 3am and mktime() doesn't change the tm struct that gets passed
to it.  Hopefully this will be taken into account by postgres shortly
(patch already sent in).  Anyway, for those interested, data from
2002-Apr-7 2am-3am is probably being stored in the year 2036 if you're
using postgres and are on a system who's mktime() implementation
doesn't alter the tm struct.  Just a heads up/FYI: this bit me hard.
-sc

--=20
Sean Chittenden

[Ruby-DBI-devel] PostgreSQL data interpretation problems...

[Sean C. <se...@ch...>]

So after digging through trace output and after diving through as many
lines of SQL logs, I found what could be a nasty date parsing problem
that could be biting folks here as well and want to give everyone a
heads up.  The following code will demonstrate the problem:

# CREATE TABLE timestamp_test (
  utc_timestamp TIMESTAMP NOT NULL
);

# INSERT INTO timestamp_tmp VALUES ('2002-4-7 2:0:0.0');

# SELECT * from timestamp_tmp;
        utc_date       =20
------------------------
 2036-06-02 22:55:24-07
(1 row)

# INSERT INTO timestamp_tmp VALUES ('2002-4-7 -8 2:0:0.0');
# SELECT * from timestamp_tmp;
        utc_date       =20
------------------------
 2036-06-02 22:55:24-07
 2002-04-07 03:00:00-07
(2 rows)


The timestamp values are generated via dbi which is problematic
because there is no easy way of getting from CST or PST to -4 or -7.
Err.. this applies to PostgreSQL and only bit me as of
yesterday/today.  -sc

--=20
Sean Chittenden

Re: [Ruby-DBI-devel] Patch for warnings with dbi/trace...

[Sean C. <se...@ch...>]

> The attached patch reduces some warnings for the dbi/trace.

Hmm...  looks like a nuance of AspectR.  The updated attached patch
should remove all warnings while using dbi/trace.  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Patch for warnings with dbi/trace...

[Sean C. <se...@ch...>]

The attached patch reduces some warnings for the dbi/trace.rb.  There
are a few more, but I think they're in the AspectR code.  For those
that are interested, I've created ports for ruby-aspectr and
ruby-rbprof for FreeBSD.  Hopefully they will be committed shortly.
-sc

-- 
Sean Chittenden

[Ruby-DBI-devel] (long) Speed differences test

[Gabriel <ga...@de...>]

I have cobbled together a short program to show speed differences
between ruby-postgres and ruby-dbi.  Again, it should be the case that
there is a SOME difference in speed, but I am showing a difference of
1000x.  I tried running this on a medium sized table (470,000 rows), and
20 hours later the DBI portion hadn't finished running.  This is of
course a contrived example, but it is typical, and doesn't make a
difference whether all rows are fetched at once or they are fetched in
bits, whether I use the sth or dbh versions, whether I use each,
fetch_array, or fetch_hash, etc.  I hope this test is properly written;
I adapted it from some production code that ran in both forms.

On a dual processor xeon 450, I got this (on about 1700 rows):
Ruby-Postgres:
0.056454
DBD::Postgres:
44.038441

On a dual processor athlon 1.2 ghz:
Ruby-Postgres:
0.017819
DBD::Postgres:
20.341243

  CODE STARTS HERE --->
  require 'postgres'
  require 'dbi'

  class QueryTiming

    def initialize
        @dbi_conn = DBI.connect('dbi:Pg:gobo','username','password')
	@pg_conn = PGconn.connect('localhost',5432,'','','gobo','username','password')
    end

    def pg_query(sql)
       rows = @pg_conn.query(sql)
       rows.each {|row|
         # do nothing on each row
       }
    end

    def dbi_query(sql)
       sth = @dbi_conn.prepare(sql)
       sth.execute()
       sth.each {|row|   sth.each {|row|
          # do nothing on each row
       }
       sth.finish()
    end

  end

 if (__FILE__ == $0)
    sql = "select doozerid,
     doozernumber, firstname, lastname,
     middlename from doozer"
    qt = QueryTiming.new
    s_time = Time.now()
    qt.pg_query(sql)
    puts("Ruby-Postgres:",Time.now() - s_time)
    s_time = Time.now()
    qt.dbi_query(sql)
    puts("DBD::Postgres:",Time.now() - s_time)
 end

Re: [Ruby-DBI-devel] Repost from Yahoo! Groups -- speed differences

[Sean C. <se...@ch...>]

> Looking at sql.rb, there is some code that does a case to type bind
> parameters. Numeric is the fall-through case, which seems odd since
> numeric ids are so common. Perhaps moving it to the top could save a
> few string comparisons?
>
> I am willing to lose a little performance in exchange for all of the
> cool things that DBI gives me, but I can't imagine the gulf should be
> so wide. I am going to continue testing and make sure I didn't just
> do something totally crazy and wrong, but in the mean time, I wonder
> if any optimization fiends want to look at the DBD_Pg and DBI code?

Could you cook up a simple table definition, the SQL that you're
using, and an example of the volumne of the data (or the type of
data)?  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Repost from Yahoo! Groups -- speed differences

[Gabriel <ga...@de...>]

Reposting, since it looks like the list changed from Yahoo to
Sourceforge.  Sorry if everyone has read this already.  I am still
looking things over to see what could be improved.  DBI seems to already
be written in a clean, efficient way...
---
Today I had a tool I wrote using DBI and DBD_Pg running for about 8
hours before I gave up and killed it, then rewrote it using plain old
ruby-postgresql. The ruby-postgresql version ran in under 2 minutes.
It was line for line just about the same, except that the
ruby-postgresql ran queries over and over from the sql string where
the DBI did a prepare before entering the loop.

I am still trying to figure out what was going on. It's a really
basic loop. I select everyone from a table, and based on the value of
a certain field, I update a few values in the row from an array. So
it's an update wrapped in a select. Probably not especially
efficient, but it shouldn't have taken as long as it did.

Looking at sql.rb, there is some code that does a case to type bind
parameters. Numeric is the fall-through case, which seems odd since
numeric ids are so common. Perhaps moving it to the top could save a
few string comparisons?

I am willing to lose a little performance in exchange for all of the
cool things that DBI gives me, but I can't imagine the gulf should be
so wide. I am going to continue testing and make sure I didn't just
do something totally crazy and wrong, but in the mean time, I wonder
if any optimization fiends want to look at the DBD_Pg and DBI code?

Thanks,
Gabriel Emerson

[Ruby-DBI-devel] ruby-dbi.sf.net (was: Re: Using DBI with Mysql problem)

[Sean C. <se...@ch...>]

> > -- mysql.so
> >  (Mysql contains mysql.so only. and I had to create mysql folder and
> > move mysql.so there as it wasn't there origionally - i checked dbd
> > spec.)
> 
> The Mysql.rb file (MySQL DBD) is missing!
> 
> You can get it manually from http://ruby-dbi.sf.net.

Eh, there's noting up on ruby-dbi.sf.net.  I'm going to toss up a
quick link and have it point over to the project page, how's that?
-sc

-- 
Sean Chittenden

Re: [Ruby-DBI-devel] Uninitialized constant Object::Date (pgsql/eRuby)...

[Sean C. <se...@ch...>]

> > > Method conv_params has a "case" statement that checks whether
> > > the passed parameter is a Date, Time or other object, and
> > > converts Date and Time objects to DBI::Date and DBI::Timestamp
> > > objects.
> > 
> > ::Date is he same as Object::Date ?
> 
> Yes, it's the same. In this case, :: could be ommitted, as there is
> no DBI::Date class.

Hmm...  this is most odd.  Ah ha!  Looks like a combination of a few
things were getting in the way and causing this problem.

1) Object::Date is set someplace inside of dbi
2) auto-reload was being used
3) auto-reload performs a basic mapping between the class name and the
   file system which was causing problems between
   /usr/local/lib/ruby/1.6/date.rb and dbi's definition of date.

> > > This error occures if there is no "Date" object. I'm sure it is
> > > a problem related to mod_ruby.

Yeah, auto-reload doesn't mesh so well with DBI: auto-reload was
finding the wrong date module (date.rb, not DBI's class Date).  The
work around is to turn off auto-reload.  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] CVS: CVSROOT loginfo,1.2,1.3

[Sean C. <the...@us...>]

Update of /cvsroot/ruby-dbi/CVSROOT
In directory usw-pr-cvs1:/tmp/cvs-serv9586

Modified Files:
	loginfo 
Log Message:
*) Activating rub...@li... as the new Ruby DBI
   CVS commit list.  See

   http://lists.sourceforge.net/lists/listinfo/ruby-dbi-devel-cvs

   for details and subscription information.


Index: loginfo
===================================================================
RCS file: /cvsroot/ruby-dbi/CVSROOT/loginfo,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- loginfo	18 Feb 2002 23:56:38 -0000	1.2
+++ loginfo	19 Feb 2002 00:04:04 -0000	1.3
@@ -24,4 +24,4 @@
 #DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog
 # or
 #DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog
-DEFAULT $CVSROOT/CVSROOT/syncmail -u %{sVv} rub...@li...
+DEFAULT $CVSROOT/CVSROOT/syncmail -u %{sVv} rub...@li...

[Ruby-DBI-devel] CVS: CVSROOT cvswrappers,1.1,1.2

[Sean C. <the...@us...>]

Update of /cvsroot/ruby-dbi/CVSROOT
In directory usw-pr-cvs1:/tmp/cvs-serv7907

Modified Files:
	cvswrappers 
Log Message:
*) Updating cvswrappers (testing commit emails: will redirect commit messages
   to rub...@li... as soon as the list is available).


Index: cvswrappers
===================================================================
RCS file: /cvsroot/ruby-dbi/CVSROOT/cvswrappers,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- cvswrappers	9 Jan 2002 22:12:07 -0000	1.1
+++ cvswrappers	18 Feb 2002 23:57:55 -0000	1.2
@@ -20,4 +20,12 @@
 #
 #  and value is a single-quote delimited value.
 # For example:
-#*.gif -k 'b'
+*.bz2 -k 'b'
+*.dat -k 'b'
+*.exe -k 'b'
+*.gif -k 'b'
+*.gz  -k 'b'
+*.jpg -k 'b'
+*.mpg -k 'b'
+*.tar -k 'b'
+*.zip -k 'b'

[Ruby-DBI-devel] CVSROOT/cvswrappers....

[Sean C. <se...@ch...>]

FYI, if a binary file type needs to get added to CVS, please edit
CVSROOT/cvswrappers or ping me with an email _before_ you type the
'cvs add' otherwise it'll add it as an ascii text file (performs line
conversions, etc: very bad).  -sc

-- 
Sean Chittenden

Re: [Ruby-DBI-devel] Uninitialized constant Object::Date (pgsql/eRuby)...

[<520...@t-...>]

Sean Chittenden wrote:
> > > Using the following query, anyone have any idea as to why I'd get
> > > the following error from below?  I'm not sure why I'm getting this
> > > error, but here's the kicker: if I push refresh on the page, it
> > > works.  I'm running about 5-10% failure for the following query
> > > and it's a tad scary that it's so inconsistent.  Anyone have any
> > > ideas?  The query doesn't even generate any dates:
> > 
> > Method conv_params has a "case" statement that checks whether the
> > passed parameter is a Date, Time or other object, and converts Date
> > and Time objects to DBI::Date and DBI::Timestamp objects.
> 
> ::Date is he same as Object::Date ?

Yes, it's the same. In this case, :: could be ommitted, as there is no DBI::Date
class. 

> > This error occures if there is no "Date" object. I'm sure it is a
> > problem related to mod_ruby.
> 
> <:~) Okey dokey.  I haven't been able to reproduce it in any other
> venue so I wasn't sure.  I'll see if I can dig up the right finalizer
> again...  Thanks.  -sc

Ok.

Regards,

  Michael

-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de

Re: [Ruby-DBI-devel] Uninitialized constant Object::Date (pgsql/eRuby)...

[<520...@t-...>]

Sean Chittenden wrote:
> Using the following query, anyone have any idea as to why I'd get the
> following error from below?  I'm not sure why I'm getting this error,
> but here's the kicker: if I push refresh on the page, it works.  I'm
> running about 5-10% failure for the following query and it's a tad
> scary that it's so inconsistent.  Anyone have any ideas?  The query
> doesn't even generate any dates:

Method conv_params has a "case" statement that checks whether the
passed parameter is a Date, Time or other object, and converts
Date and Time objects to DBI::Date and DBI::Timestamp objects.


> sql = 'SELECT [VARCHAR(20)], ([INT4] / 1024.0 / 1024.0) FROM....'
> 
> dbh.select_all(sql, username) do |row|  # This is line 75 in index.rhtml
> 
> /usr/local/lib/ruby/site_ruby/1.6/dbi/utils.rb:12:in `conv_param': uninitialized constant Object::Date (NameError)
>      from /usr/local/lib/ruby/site_ruby/1.6/dbi/utils.rb:10:in `collect'


This error occures if there is no "Date" object. I'm sure it is 
a problem related to mod_ruby. 


Regards,

  Michael


-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de

Re: [Ruby-DBI-devel] Uninitialized constant Object::Date (pgsql/eRuby)...

[Sean C. <se...@ch...>]

> > Using the following query, anyone have any idea as to why I'd get
> > the following error from below?  I'm not sure why I'm getting this
> > error, but here's the kicker: if I push refresh on the page, it
> > works.  I'm running about 5-10% failure for the following query
> > and it's a tad scary that it's so inconsistent.  Anyone have any
> > ideas?  The query doesn't even generate any dates:
> 
> Method conv_params has a "case" statement that checks whether the
> passed parameter is a Date, Time or other object, and converts Date
> and Time objects to DBI::Date and DBI::Timestamp objects.

::Date is he same as Object::Date ?

> This error occures if there is no "Date" object. I'm sure it is a
> problem related to mod_ruby.

<:~) Okey dokey.  I haven't been able to reproduce it in any other
venue so I wasn't sure.  I'll see if I can dig up the right finalizer
again...  Thanks.  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Uninitialized constant Object::Date (pgsql/eRuby)...

[Sean C. <se...@ch...>]

Using the following query, anyone have any idea as to why I'd get the
following error from below?  I'm not sure why I'm getting this error,
but here's the kicker: if I push refresh on the page, it works.  I'm
running about 5-10% failure for the following query and it's a tad
scary that it's so inconsistent.  Anyone have any ideas?  The query
doesn't even generate any dates:

sql = 'SELECT [VARCHAR(20)], ([INT4] / 1024.0 / 1024.0) FROM....'

dbh.select_all(sql, username) do |row|  # This is line 75 in index.rhtml

/usr/local/lib/ruby/site_ruby/1.6/dbi/utils.rb:12:in `conv_param': uninitialized constant Object::Date (NameError)
     from /usr/local/lib/ruby/site_ruby/1.6/dbi/utils.rb:10:in `collect'
     from /usr/local/lib/ruby/site_ruby/1.6/dbi/utils.rb:10:in `conv_param'
     from /usr/local/lib/ruby/site_ruby/1.6/dbi/dbi.rb:554:in `execute'
     from /usr/local/lib/ruby/site_ruby/1.6/dbi/dbi.rb:585:in `select_all'
     from /tmp/index.rhtml.97187.0:75
     from /usr/local/lib/ruby/site_ruby/1.6/apache/eruby-run.rb:104:in `load'
     from /usr/local/lib/ruby/site_ruby/1.6/apache/eruby-run.rb:104:in `run'
     from /usr/local/lib/ruby/site_ruby/1.6/apache/eruby-run.rb:72:in `handler'
     from ruby:0


Anyone have any thoughts?  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] CVS Repo at SourceForge...

[Sean C. <se...@ch...>]

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ruby-dbi/

'nuff said.  -sc

-- 
Sean Chittenden

[Ruby-DBI-devel] Welcome to ruby-dbi, $SAFE = 1? (was: Re: CVS repo...)

[Sean C. <se...@ch...>]

> > Sounds good.  If worse comes to worse I can just import the current
> > sources and would loose some of the history....  <:~(  -sc
> 
> http://ruby-projects.org/downloads/cvsroot.tgz
> 
> There is a webupdater included. I don't think we'll need it...

Hey.  I think this'd be a decent 1st post for the list.  Just wanted
to drop a quick FYI that the import should be done shortly (hopefully
by the end of the weekend).  I nuked the html area and the webupdater
from the downloaded cvsroot for now because they were only at 1.1.
I've got a backup of it just in case.

At any rate, ruby-dbi.sourceforge.net is up, but empty.  On a technical
note, what are the odds of being able to change the Directory globing
and File globing so that it doesn't use *?  Michael, would you object
if I tossed up a patch for review to handle that?  Under mod_ruby
(safe level 1) it's impossible to use the available_drivers class
method w/o tripping a security error.  Quite frustrating.  <:~)  -sc

-- 
Sean Chittenden