|
Re: Seemingly Internal DBD-XBase Error
by Fastolfe (Vicar) on Dec 22, 2000 at 01:11 UTC
|
It might help to see the code you are using to instantiate your DBI object. I know you said your code is flawless, but you have no idea what percentage of the time somebody says that and they are wrong. It might help to assure us with a snippet that you are creating your DBI object correctly before we spend time debugging a Perl module that is arguably working fine for others.
Unfortunately I don't have a copy of DBD::XBase or else I'd try further. Could we perhaps see this line it's referring to (perhaps with a bit of context)? Is there any way you can trace the flow of execution from your script into this module to determine what it's trying to do with this undefined object and why it might be undefined? | [reply] |
|
|
my $dbh = DBI->connect("DBI:XBase:m:\\") or die $DBI::errstr;
my $sth = $dbh->prepare("select custnum FROM cms where order = 1002");
$sth->execute() or die $sth->errstr();
my @data;
my $i = 0;
while (@data = $sth->fetchrow_array()) {
print "$data$i\n";
$i++;
}
Here's the code in XBase.pm that's giving the error. Line 337 is $xbase = new XBase(%opts) or do
# let's see if we've already opened the table
my $xbase = $dbh->{'xbase_tables'}->{$table};
if (not defined $xbase)
{ # if not, open the table now
my $filename = $dbh->{'Name'} . '/' . $table;
my %opts = ('name' => $filename);
$opts{'ignorememo'} = 1 if $dbh->{'xbase_ignorememo'};
# try to open the table using XBase.pm
$xbase = new XBase(%opts) or do
{
$sth->DBI::set_err(3, "Table $table not found: "
. XBase->errstr());
return;
};
$dbh->{'xbase_tables'}->{$table} = $xbase;
}
| [reply] |
|
|
Um... What's this?
my $dbh = DBI->connect("dbi:XBase:
m:\\") ...
Could it be that you're using the delimiter for the
connect string within your directory specification? That's
a small hazardous guess, since I haven't used DBD::XBase,
but since ':' is the standard delimiter, you may have to
find a different manner of specfifying directory.
Also, after using DBI with Oracle and MS SQL Server, and
just recently MySQL, I have to say that DBD:XBase has one of
the strangest connect strings I've seen. Try this to get a
better understanding of what the connect string is seeing:
DBI->trace(3);
$dbh = DBI->connect("dbi:XBase:m:\\");
UPDATE: Is it safe to presume that you don't need
a user and password for your dbf file? Looking at
the trace output immediately below this post, it appears
that you get a database handle, but the statement handle is
what's creating the error. That's as far down the road as I
can take you, young monk, but it may be enough to put it all
together.
ALL HAIL BRAK!!! | [reply]
[d/l]
[select] |
|
|
|
|
|
|
I'm wondering if the code is assuming its object class is XBase instead of DBD::XBase? Perhaps somebody else that actually has this module can do some "real" debugging? Good luck.
| [reply]
[d/l]
[select] |
Re: Seemingly Internal DBD-XBase Error
by mvaline (Friar) on Dec 22, 2000 at 02:15 UTC
|
The trace output reminded me that I wasn't using -w because I was simply executing the script using the Windows file extension alias. When I turned that on, I saw the following errors.
Subroutine driver redefined at C:/Perl/lib/DBD/XBase.pm line 32.
Subroutine data_sources redefined at C:/Perl/lib/DBD/XBase.pm line 51.
Subroutine connect redefined at C:/Perl/lib/DBD/XBase.pm line 64.
Subroutine disconnect_all redefined at C:/Perl/lib/DBD/XBase.pm line 78.
Subroutine prepare redefined at C:/Perl/lib/DBD/XBase.pm line 91.
Subroutine STORE redefined at C:/Perl/lib/DBD/XBase.pm line 119.
Subroutine FETCH redefined at C:/Perl/lib/DBD/XBase.pm line 128.
Subroutine tables redefined at C:/Perl/lib/DBD/XBase.pm line 138.
Subroutine quote redefined at C:/Perl/lib/DBD/XBase.pm line 153.
Subroutine commit redefined at C:/Perl/lib/DBD/XBase.pm line 164.
Subroutine rollback redefined at C:/Perl/lib/DBD/XBase.pm line 170.
Subroutine disconnect redefined at C:/Perl/lib/DBD/XBase.pm line 178.
Subroutine table_info redefined at C:/Perl/lib/DBD/XBase.pm line 191.
Subroutine type_info_all redefined at C:/Perl/lib/DBD/XBase.pm line 225.
Subroutine type_info redefined at C:/Perl/lib/DBD/XBase.pm line 234.
Subroutine DESTROY redefined at C:/Perl/lib/DBD/XBase.pm line 245.
Subroutine bind_param redefined at C:/Perl/lib/DBD/XBase.pm line 261.
Subroutine rows redefined at C:/Perl/lib/DBD/XBase.pm line 269.
Subroutine _set_rows redefined at C:/Perl/lib/DBD/XBase.pm line 273.
Subroutine execute redefined at C:/Perl/lib/DBD/XBase.pm line 283.
Subroutine fetch redefined at C:/Perl/lib/DBD/XBase.pm line 544.
Subroutine FETCH redefined at C:/Perl/lib/DBD/XBase.pm line 591.
Subroutine STORE redefined at C:/Perl/lib/DBD/XBase.pm line 628.
Subroutine finish redefined at C:/Perl/lib/DBD/XBase.pm line 638.
Subroutine DESTROY redefined at C:/Perl/lib/DBD/XBase.pm line 640.
Subroutine fetchrow_arrayref redefined at C:/Perl/lib/DBD/XBase.pm line 588.
Could I somehow have two copies of XBase installed? | [reply] |
|
|
Possibly, but it's more likely to be reporting the fact that
the DBD is overriding the functions of the DBI.
Can anyone verify that?
ALL HAIL BRAK!!!
| [reply] |
|
|
Do you have an explicit 'use DBD::Xbase;' in your code? If so, try removing it. DBI loads the appropriate modules for you when you call the connect method.
| [reply] |
|
|
I don't explicitly use DBD::XBase. However, the XBase.pm that we've been talking about is DBD::XBase. The top of XBase.pm is as follows.
use strict;
use DBI (); # we want DBI
use XBase; # and we want the basic XBase handling modules
use XBase::SQL; # including the SQL parsing routines
use Exporter;
Could it be possible that it is confusing itself with the XBase it mentions? How do I check if I have that XBase even installed? If I use PPM and query XBase it checks on DBD-XBase. | [reply] |
|
|
|
|