headers
Hal Wigoda | 4 Sep 2006 02:23
Picon

DBD/DBI datetime insert

anyone have the code that will insert the current time into a  
datetime field in a table
while using perl DBI/DBD::mysql?

--

-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules <at> m.gmane.org
Permalink | Reply | 1 comment |
headers
Kenny Scott | 4 Sep 2006 15:15
Picon
Favicon

Re: DBD/DBI datetime insert

Hal Wigoda wrote:

>  anyone have the code that will insert the current time into a
>  datetime field in a table while using perl DBI/DBD::mysql?

Hi,

Hopefully this will give you enough pointers.

-- 
Kenny

#!/usr/bin/perl -w

use strict;
use DBI;

my $dbh = DBI->connect( "DBI:mysql:test", "root", "");
my $sth = $dbh->prepare( "INSERT INTO a VALUES ( NOW() )" );
$sth->execute();
$sth->finish();

$sth = $dbh->prepare( "SELECT a FROM a" );
$sth->execute();
my ( $time ) = $sth->fetchrow_array();
$sth->finish();

print "The time was [$time]\n";

$dbh->disconnect();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ruprecht Helms | 4 Sep 2006 16:55
Picon
Favicon

handling with variable


Hi,

how can I work with variables within a perl-script using DBI.
I want to read content of tablefields into variables to compute with it.
The result of the computing should be written into another field of
another table.

A little scriplet would be nice.

Regards,
Ruprecht
Permalink | Reply | 1 comment |
headers
Patrick Galbraith | 4 Sep 2006 17:04
Picon
Favicon

Re: Memory access problem with DBI or DBD-Mysql?

Federico,

That may be the issue. I have encountered this issue in other parts of 
the driver. There is a better way to do this, and I can look at making 
sure what is being passed is the same data object.

Thanks!

Patrick

Federico Giannici wrote:

> Since there has been no reply to my previous message, I have done 
> further investigations trying to find the problem.
>
> Please note that my knowledge of DBI/DBD is almost null, so the 
> followings are only simple suppositions.
>
> I have seen that mysql_st_internal_execute() function is executed by 
> both the "do" and "execute" methods. It seems that the problems are 
> only with the "do" method and not with the "execute", so I looked for 
> the differences between them.
>
> The main difference seems to be that "execute" passes a STATEMENT 
> handle as first argument, while "do" passes a DATABASE handle. The 
> mysql_st_internal_execute() function uses this handle to obtain the 
> sth and then from this one the dbh.
>
> So, my hypothesis is that if the initial handle is a database one, the 
> sth (and the derived dbh) obtained from this is not a valid one!
(Continue reading)

Permalink | Reply | 16 comments |
headers
Martin J. Evans | 4 Sep 2006 18:50
Favicon

RE: handling with variable

Not actually tested but the basic principle is:

my $dbh = DBI->connect(...);
my $sth = $dbh->prepare(q/select col1, col2 from table where col3=1/);
my ($col1, $col2);
$sth->bind_col(1, \$col1);
$sth->bind_col(2, \$col2);
$sth->fetch;
my $result = $col1 + $col2;
$sth = $dbh->prepare(q/insert into table2 values(?)/);
$sth->execute($result);

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com

On 04-Sep-2006 Ruprecht Helms wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> how can I work with variables within a perl-script using DBI.
> I want to read content of tablefields into variables to compute with it.
> The result of the computing should be written into another field of
> another table.
> 
> A little scriplet would be nice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Federico Giannici | 9 Sep 2006 11:07
Picon

Re: Memory access problem with DBI or DBD-Mysql?

Hi Patrick,
are there any news about this bug?

Someone made me notice that there a few other "tickets" open on this bug 
(under i386 and amd64), like this one:

http://rt.cpan.org/Public/Bug/Display.html?id=20868

Thanks.

Patrick Galbraith wrote:
> Federico,
> 
> That may be the issue. I have encountered this issue in other parts of 
> the driver. There is a better way to do this, and I can look at making 
> sure what is being passed is the same data object.
> 
> Thanks!
> 
> Patrick
> 
> Federico Giannici wrote:
> 
>> Since there has been no reply to my previous message, I have done 
>> further investigations trying to find the problem.
>>
>> Please note that my knowledge of DBI/DBD is almost null, so the 
>> followings are only simple suppositions.
>>
>> I have seen that mysql_st_internal_execute() function is executed by
(Continue reading)

Permalink | Reply | 14 comments |
headers
Patrick Galbraith | 11 Sep 2006 14:53
Picon
Favicon

DBD::mysql 3.0007 and 3.0007_1 (Dev) released!

Dear DBD::mysql users and developers,

DBD::mysql version 3.0007 (stable, production) and 3.0007_1 (dev) have 
been released!

Version 3.0007 is the production version with server-side prepare
statements turned off by default, and 3.0007_1 is the development
version with server-side prepare statements turned on by default.

Changes in 3.0007/3.0007_1, from ChangeLog:

* Make sure to call dbd_st_finish when all rows from a statement handle
    have been fetched. (Bug #20153, Bug# 21607, as rt.cpan.org ticket #s
    20464, 21241) Jim Winstead
  * Patch from Steve Hay to fix bind_param to deal properly with insertion
    of a NULL into an INT or DOUBLE column using server-side prepare.
    Converted Steve's dbi.pl script to expose this problem to 40bindparam2
    test.
  * Fix to mysql_st_internal_execute to keep from passing undefined dbh
    handle member (bind_type_guessing) to parse_param causing crash on
    OpenBSD. Reported on rt.cpan.org (#20868) by Kyle Georg, as well as
    info from Sam Smith and Federico Giannici
  * Cleaned up tests to make sure test table is dropped at end of test.

Notes:

* To turn ON server-side prepared statements (only in 3.0007 non-dev 
release),
simply append ";mysql_server_prepare=1" to the connect string or via the 
driver
(Continue reading)

Permalink | Reply | 0 comments |
headers
Federico Giannici | 11 Sep 2006 15:39
Picon

Re: Memory access problem with DBI or DBD-Mysql?

Hi Patrick,
I have seen that version 3.0007 has been released and it (should) have 
fixed that bug.
But...

1) In mysql_st_internal_execute() the "bind_type_guessing" variable is 
correctly set, but then it's NOT used: "imp_dbh->bind_type_guessing" is 
still used!

2) mysql_st_internal_execute() is used in only two places. Instead of 
doing all that tests at the beginning of the function to handle both 
cases (STH and DBH for the "h" parameter), why don't you change the type 
of the first parameter into a "imp_dbh"? Wouldn't everything be clearer 
this way?

Bye.

Federico Giannici wrote:
> Hi Patrick,
> are there any news about this bug?
> 
> Someone made me notice that there a few other "tickets" open on this bug 
> (under i386 and amd64), like this one:
> 
> http://rt.cpan.org/Public/Bug/Display.html?id=20868
> 
> Thanks.
> 
> 
>
(Continue reading)

Permalink | Reply | 12 comments |
headers
ORANSKY, JEFF (SBCSI | 11 Sep 2006 20:36
Picon
Favicon

DBD::mysql problem

I am installing DBD::mysql on an IBM AIX 5.2 system.  We are using Mysql
5.0.24a. It compiles ok, but when I do a make test I get the error
below.
When I try to look for the code, for example, for mysql_stmt_close I
cannot find it in the mysql libraries.
Any idea why this is, or am I mising a library that I need for mysql?

mysql <at> pida4907> ls
	libdbug.a                   libmysqlclient_r.a
	libmygcc.a                  libmysqlclient_r.a-32bit
	libmysql.imp                libmysqlclient_r.a.Biskid
	libmysqlclient.a            libmysqlclient_r.a.ORIG
	libmysqlclient.a-32bit      libmysqlclient_r.a.Pickard
	libmysqlclient.a.Biskid     libmystrings.a
	libmysqlclient.a.ORIG       libmysys.a
	libmysqlclient.a.Pickard    libz.a
mysql <at> pida4907> nm -rp *.a | grep mysql_stmt_close
mysql <at> pida4907>

PERL_DL_NONLAZY=1 /home/datagate/bldmstr1/usr/local/bin/perl
"-MExtUtils::Command::MM" "-e" "test_harness(
0, 'blib/lib', 'blib/arch')" t/*.t
t/00base.............install_driver(mysql) failed: Can't load
'/home/datagate/bldmstr1/perl_modules/DBD-mysql-3.00
06/blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: rtld:
0712-001 Symbol mysql_stmt_close was referenced
      from module
/home/datagate/bldmstr1/perl_modules/DBD-mysql-3.0006/blib/arch/auto/DBD
/mysql/mysql.so(), but a
 runtime definition
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Smith | 11 Sep 2006 21:50

Re: Memory access problem with DBI or DBD-Mysql?

On Mon, 11 Sep 2006, Federico Giannici wrote:
> I have seen that version 3.0007 has been released and it (should) have fixed 
> that bug.

I'm still seeing segfaults with 3.0007

gdb /usr/bin/perl
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.0"...(no debugging symbols found)

(gdb) target core perl.core
Core was generated by `perl'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libperl.so.10.1...
done.
Loaded symbols for /usr/lib/libperl.so.10.1
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Reading symbols from /usr/lib/libutil.so.11.0...done.
Loaded symbols for /usr/lib/libutil.so.11.0
Reading symbols from /usr/lib/libc.so.39.2...done.
Loaded symbols for /usr/lib/libc.so.39.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Reading symbols from /usr/local/libdata/perl5/site_perl/i386-openbsd/auto/DBI/DBI.so...done.
(Continue reading)

Permalink | Reply | 6 comments |

Gmane