Re: Unable to run sample code from DBD::DBM on Strawberry Perl



On Feb 26, 11:25 am, Steve C <smallp...@xxxxxxxx> wrote:

These are not perl errors, they are errors in your
understanding of how a database works.  You can't
create a new table if a table already exists with
that name.  If you don't want the old one, you need
to DROP it first.


I understand that. But the first time I run the script, there is
no database by the name 'user'. Therefore, it shouldn't be
complaining that the 'user' table already exists.

In fact, just to make sure, I went ahead and added "DROP TABLE
user;" to my script, just like you said (I also commented out the
'RaiseError' line), making it look like this:

use DBI;
my $dbh = DBI->connect('dbi:DBM:');
# $dbh->{RaiseError} = 1;
for my $sql( split /;\n+/,"
DROP TABLE user;
CREATE TABLE user ( user_name TEXT, phone TEXT );
INSERT INTO user VALUES ('Fred Bloggs','233-7777');
INSERT INTO user VALUES ('Sanjay Patel','777-3333');
INSERT INTO user VALUES ('Junk','xxx-xxxx');
DELETE FROM user WHERE user_name = 'Junk';
UPDATE user SET phone = '999-4444' WHERE user_name = 'Sanjay
Patel';
SELECT * FROM user
"){
my $sth = $dbh->prepare($sql);
$sth->execute;
$sth->dump_results if $sth->{NUM_OF_FIELDS};
}
$dbh->disconnect;

Now when I run the script, I see:

Execution ERROR: Table 'user' already exists..
DBD::DBM::st execute failed: Can't call method "column" on an
undefined value at C:/strawberry/perl/site/lib/SQL/Statement/Term.pm
line 190.
[for Statement " DELETE FROM user WHERE user_name = 'Junk'"] at
dbi_dbm.pl line 15.
Execution ERROR: Column 'phone' not known in any table called from C:/
strawberry/perl/site/lib/DBD/File.pm at 446.
Execution ERROR:
Execution ERROR: Column 'phone' not known in any table called from C:/
strawberry/perl/site/lib/DBD/File.pm at 446.
called from dbi_dbm.pl at 15.
Execution ERROR:
Execution ERROR:
Execution ERROR: Column 'phone' not known in any table called from C:/
strawberry/perl/site/lib/DBD/File.pm at 446.
called from dbi_dbm.pl at 15.
..
undef, undef
undef, undef
undef, undef
3 rows

Notice that the Execution ERROR stating that table 'user' already
exists is still reported. I don't think it's my understanding that's
in error here. (Especially since the example script (as shown in
"perldoc DBD::DBM") worked just fine for time the first time I ran it
in Linux.)

(What I'm trying to say is, if "DROP TABLE user;" was required to
run the example the first time, then the perldocs would have given a
faulty script by not including that line.)


Why do you think deleting the files is the right thing to do?
If you want to use a database, learn how first. Don't just guess.

Because when I ran the script it created those three new files,
each beginning with "user". That's consistent with what I know of DBM
databases, in that the DBM data is stored in files beginning with the
database name. (At least, that's the behavior I've seen with all the
DBM databases I've tinkered with.)

But if you have a concrete example that contradicts mine, please
show it to me. I mentioned that I deleted the "user*" files to
indicate that I shouldn't have any DBM files hanging around that begin
with "user". But if the table already exists because it's stored in
some other file (thus proving my assumption false), I'd definitely
like to know.

The fact that I could see the inserted data (with a hex editor) in
the "user.pag" file seems to reinforce my assumption.

But if you can prove my assumption wrong (which is that the
database data is held in the "user*" files), please do so! I would
appreciate having that false assumption corrected (if it is indeed
false).

Cheers,

-- Jean-Luc
.



Relevant Pages

  • Re: Unable to run sample code from DBD::DBM on Strawberry Perl
    ... understanding of how a database works. ... Execution ERROR: Column 'phone' not known in any table called from C:/ ... undef, undef ... That's consistent with what I know of DBM ...
    (comp.lang.perl.misc)
  • Re: Get custom database properties from an Access database
    ... It doesn't matter if the VBScript process drags, since it is an independent process and so will have no effect on the user's interaction with the database. ... The user can skip merrily along, doing whatever he needs while the script invisibly figures out the current situation in the background and decides what to do about it. ... It does, but I've run into issues other places on this same network, where users needed a drive letter to a server. ...
    (microsoft.public.scripting.vbscript)
  • Re: Get custom database properties from an Access database
    ... write the script to look for an available letter, ... If you're concerned about another drive letter causing ... will have no effect on the user's interaction with the database. ... As for the server, yes, that would definitely be the way to go. ...
    (microsoft.public.scripting.vbscript)
  • Re: Get custom database properties from an Access database
    ... will write the script to look for an available letter, ... If you're concerned about another drive letter causing ... will have no effect on the user's interaction with the database. ... As for the server, yes, that would definitely be the way to go. ...
    (microsoft.public.scripting.vbscript)
  • [NEWS] IBM Informix Web DataBlade Local Root by Design
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... that ease development of "intelligent", interactive, Web-enabled database ... person who has access to change the Perl script. ...
    (Securiteam)