Re: DBD::Sybase, dbiproxy, and the table_info method...

[Edward J. Sabol]

Hmmm. No response to my last e-mail. Is there *anyone* using dbiproxy, DBI
1.18, and DBD::Sybase

In my last last e-mail from 21 June 2001:
> Previously, I wrote:
>>> I just finished upgrading a bunch of modules. I upgraded from DBI 1.13 to
>>> 1.18, DBD::Sybase 0.21 to 0.91, Net::Daemon 0.29 to 0.35, and Storable 0.6.7
>>> to 1.0.11. I also had to upgrade File::Spec since my File::Spec didn't have
>>> the tmpdir method which DBI::ProxyServer.pm now uses. (I'm still using Perl
>>> 5.005_03.)
>
> I might have been wrong about this working before I upgraded all those
> modules. I could have sworn that my table_info script used to work via
> dbiproxy, but I just reverted all of the above modules (except for
> File::Spec) back to the versions I was using previously, and table_info still
> isn't working.
>
> Unfortunately, I didn't have debug turned on in my dbiproxy logfile, so I
> can't prove it definitively one way or the other, though I did notice a fair
> number of 'Can't call method "execute" without a package or object reference
> at /usr/contrib/lib/perl5/site_perl/5.005/alpha-dec_osf/DBD/Sybase.pm line
> 151' errors in my non-debug dbiproxy logfile going back over the past year.
>
> Michael Peppler responded:
>> This would mean that the prepare() call in DBD::Sybase's table_info()
>> returns undef - but that *should* only happen if you already have an
>> active statement handle on that connection, and if DBD::Sybase is
>> unable to open a new connection.
>
> Michael, does the table_info method work for you via dbiproxy?
>
> Any suggestions on how I should proceed to get to the bottom of this?

Re: DBD::Sybase, dbiproxy, and the table_info method...

[Edward J. Sabol]

Previously, I wrote:
>> I just finished upgrading a bunch of modules. I upgraded from DBI 1.13 to
>> 1.18, DBD::Sybase 0.21 to 0.91, Net::Daemon 0.29 to 0.35, and Storable 0.6.7
>> to 1.0.11. I also had to upgrade File::Spec since my File::Spec didn't have
>> the tmpdir method which DBI::ProxyServer.pm now uses. (I'm still using Perl
>> 5.005_03.)

I might have been wrong about this working before I upgraded all those
messages. I could have sworn that my table_info script used to work via
dbiproxy, but I just reverted all of the above modules (except for
File::Spec) back to the versions I was using previously, and table_info still
isn't working.

Unfortunately, I didn't have debug turned on in my dbiproxy logfile, so I
can't prove it definitively one way or the other, though I did notice a fair
number of 'Can't call method "execute" without a package or object reference
at /usr/contrib/lib/perl5/site_perl/5.005/alpha-dec_osf/DBD/Sybase.pm line
151' errors in my non-debug dbiproxy logfile going back over the past year.

Michael Peppler responded:
> This would mean that the prepare() call in DBD::Sybase's table_info()
> returns undef - but that *should* only happen if you already have an
> active statement handle on that connection, and if DBD::Sybase is
> unable to open a new connection.

Michael, does the table_info method work for you via dbiproxy?

Any suggestions on how I should proceed to get to the bottom of this?

Re: DBD::Sybase, dbiproxy, and the table_info method...

[Edward J. Sabol]

> Can you run the same script on the dec/alpha host using DBD::Sybase
> directly?

Yes, the identical script (which is very simple, it just connects, calls
the table_info method, and uses fetchall_arrayref to get the results from the
table_info method) works on the same host that dbiproxy is running on and
using DBD::Sybase directly. I also used this same test script with my old
setup and it worked fine (both through dbiproxy and directly to DBD::Sybase).

DBD::Sybase, dbiproxy, and the table_info method...

[Edward J. Sabol]

I just finished upgrading a bunch of modules. I upgraded from DBI 1.13 to
1.18, DBD::Sybase 0.21 to 0.91, Net::Daemon 0.29 to 0.35, and Storable 0.6.7
to 1.0.11. I also had to upgrade File::Spec since my File::Spec didn't have
the tmpdir method which DBI::ProxyServer.pm now uses. (I'm still using Perl
5.005_03.)

Everything works the same as it did prior to these upgrades except for one
thing: When connecting to my Sybase server via DBD::Proxy and my dbiproxy
server, the table_info method (with no arguments) doesn't work. (It works
fine if I don't go through dbiproxy though.) Normal prepare/execute/fetchall
code sequences work fine through dbiproxy. Only table_info seemingly has
problems. (Yes, I restarted the dbiproxy server after finishing all of the
aforementioned upgrades.)

Here's the dbiproxy log entries with debug turned on:

Wed Jun 20 15:48:40 2001 debug, Connection from 128.xxx.xxx.xxx, port 3301
Wed Jun 20 15:48:40 2001 debug, Child clone: DBI::ProxyServer=HASH(0x1403971f0)

Wed Jun 20 15:48:40 2001 debug, New child starting 
(DBI::ProxyServer=HASH(0x1403971f0)).
Wed Jun 20 15:48:40 2001 debug, Accepting client from 128.xxx.xxx.xxx, port 3301
Wed Jun 20 15:48:40 2001 debug, Client logs in: Application dbi:Sybase:SYBASE, version 
0.2003, user x
Wed Jun 20 15:48:40 2001 debug, Connecting to dbi:Sybase:SYBASE as x
Wed Jun 20 15:48:40 2001 debug, Accepting client
Wed Jun 20 15:48:40 2001 debug, Client executes method CallMethod
Wed Jun 20 15:48:40 2001 debug, CallMethod: => 
DBI::ProxyServer::db=HASH(0x1403a26c8),STORE,AutoCommit,1
Wed Jun 20 15:48:40 2001 debug, CallMethod: <= 1
Wed Jun 20 15:48:40 2001 debug, Client executes method CallMethod
Wed Jun 20 15:48:40 2001 debug, CallMethod: => 
DBI::ProxyServer::db=HASH(0x1403a26c8),table_info
Wed Jun 20 15:48:40 2001 err, Can't call method "execute" without a package or object 
reference at /usr/contrib/lib/perl5/site_perl/5.005/alpha-dec_osf/DBD/Sybase.pm line 
151.

Looking at the DBI Changes file, under the Proxy section for the DBI 1.15
release, there is the following change listed: "Added fix for problem using
table_info thanks to Tom Lowery." There are a few other changes to Proxy
there as well, as well as one listed under DBI 1.16: "Fixed client sql
restrictions in ProxyServer.pm thanks to Jochen Wiedmann."

I don't see anything relevant looking at DBD::Sybase's CHANGES file. The
changes to Net::Daemon look pretty trivial to me and unrelated. Storable is a
black hole to me.

Any idea what the problem might be? Is there anyone using the DBD::Proxy and
dbiproxy from DBI 1.18 that has a working table_info method?

Thanks,
Ed

Anyone else experiencing problems with the dbi-* mailing lists?

[Edward J. Sabol]

Is there a problem with the [EMAIL PROTECTED], [EMAIL PROTECTED], and
[EMAIL PROTECTED] mailing lists? I seem to be experiencing sporadic
delivery problems.

Recently, I noticed that I haven't received a single e-mail from
[EMAIL PROTECTED] since May 11th or [EMAIL PROTECTED] since May 4th. Both
of those are low-volume mailing lists, so that's somewhat plausible. However,
although I have received e-mail from [EMAIL PROTECTED], I noticed that the
volume of posts that I have received has dropped drastically. For example,
between May 22nd and June 1st, I received *one* e-mail from
[EMAIL PROTECTED] Since then, there has been some improvement, but it's
still a trickle compared to what the volume was just a couple months ago. And
the e-mails I do receive from [EMAIL PROTECTED] often refer to e-mails that
I haven't received.

At first, I thought maybe I had been unsubscribed from dbi-announce and/or
dbi-dev, so I sent e-mail to [EMAIL PROTECTED], but I received
no response from the list server. I also tried to send e-mail to
[EMAIL PROTECTED] and didn't get any response there either. Next I
tried [EMAIL PROTECTED] Again no response. The e-mail I sent to
[EMAIL PROTECTED] has gone unanswered for two days as well.

So I decided to check the mailing list archives to see what's going on.
 referred me to the mailing list archives at
, but I couldn't access that web site at all.
No response at all to my HTTP connections.

Next, I checked the DBI home page at . It has
links to two other mailing list archives: One at
 and another one at
. But I
couldn't get a response from outside.organic.com either! Fortunately, the
fine folks at MPE have figured out how to correctly administer a web site.

I also checked my old dbi-* e-mails and found a link to a mailing list
archive at . I was able to access
that site as well.

Comparing the mailing list archive at theaimsgroup.com with the mailing list
at MPE, the MPE archive seems to be complete, but theaimsgroup.com archive is
missing e-mails that the MPE archive has received. It's also missing e-mails
that I've received. Both the MPE archive and theaimsgroup.com archive contain
lots of e-mails that I haven't received. MPE has archived 242 dbi-users
e-mails in the month of June, theaimsgroup.com has archived 22, and I've
received even less than that.

I'm subscribed to a dozen mailing lists from places other than perl.org and
I'm receiving e-mail from all of these other lists just fine, so I don't
think it's a problem with my machine. My workstation has been turned on and
connected to the Internet 24/7 for years now, and I've been subscribed to the
dbi-* mailing lists since April 1997. Looking at the dbi-users archive at
, I'm more convinced of that than
ever, since they seem to be experiencing the same problem as me.

Anyone have clue what's going on? Anyone else experiencing this? I've checked
my mail logs and the e-mails just aren't getting here. I wonder if maybe
lists.perl.org has bitten off more than it can chew. Perhaps at various times
their load becomes so high that sendmail processes are being terminated
before they finish propagating an e-mail to all the members of the mailing
list?

Needless to say, please CC: me on all responses and/or follow-ups. I've set
the Reply-To: header on this e-mail accordingly. But I don't trust that the
mailing list server will send any e-mails to me. (I estimate that I have a 1
in 5 chance of receiving a particular dbi-users e-mail from the mailing list
server.)

Thanks,
Ed