Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_IDand SERVER_PREPARE

Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_IDand SERVER_PREPARE_VERSION

am 02.04.2006 13:36:41 von Martin.Evans

Hi,

I could really do with a little assistance form the dbd::mysql
maintainers or authors please.

I am investigating the issue I reported here with execute_array or all
executes failing after one execute fails.

i.e.
create table test (a int primary key)
prepare(insert into test values(?)
execute(1) - OK
execute(2) - OK
execute(1) - fails but expected
execute(3) - fails but row inserted and not expected to fail

It appears this has something to do with whether MYSQL_VERSION_ID is <=
SERVER_PREPARE_VERSION.

My myql is 50015 and my client lib is also 50015 - as client and server
are on the same machine.
SERVER_PREPARE_VERSION is 40103 (in dbimp.h)

When I run with dbd::mysql (from 3.0002_4) it fails.
When I turn all comparisons of MYSQL_VERSION_ID >=
SERVER_PREPARE_VERSION around so it is < it works.
Can someone tell my if dbd_st_execute is supposed to call
mysql_st_internal_execute41 for versions of MySQL
40103 and lower or the opposite way around. I suspect it should be:

if MYSQL_VERSION_ID < SERVER_PREPARE_VERSION
use mysql_st_internal_execute41

because other places in the code do things like:

#if MYSQL_VERSION_ID < SERVER_PREPARE_VERSION
if (mysql_real_query(&imp_dbh->mysql, "COMMIT", 6))
#else
if (mysql_commit(&imp_dbh->mysql))
#endif

because functions like mysql_commit were introduced in 4.1

I'd greatly appreciate any help here as I'm desparately trying to make
this work and trying very hard to feedback problems and fixes to DBD::mysql.

Martin

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_IDand SERVER_PREPARE_VERSION

am 08.04.2006 01:49:05 von Patrick Galbraith

Martin,

Thanks for the info. Do you have a script that does this?
mysql_st_execute41 should be called if mysql supports prepared
statements, that is, >= SERVER_PREPARE_VERSION. I'm a bit suprised it
works, but I think I have code that catches it even if it doesn't
support prepared statements, so mysql_st_execute41 might have better
handling, even for versions < 4.1. Please send whatever script you have
to reproduce this. I'd like to see why it works where it shouldn't and
where it doesn't where it should.

Kind regards,

Patrick

Martin J. Evans wrote:

> Hi,
>
> I could really do with a little assistance form the dbd::mysql
> maintainers or authors please.
>
> I am investigating the issue I reported here with execute_array or all
> executes failing after one execute fails.
>
> i.e.
> create table test (a int primary key)
> prepare(insert into test values(?)
> execute(1) - OK
> execute(2) - OK
> execute(1) - fails but expected
> execute(3) - fails but row inserted and not expected to fail
>
> It appears this has something to do with whether MYSQL_VERSION_ID is
> <= SERVER_PREPARE_VERSION.
>
> My myql is 50015 and my client lib is also 50015 - as client and
> server are on the same machine.
> SERVER_PREPARE_VERSION is 40103 (in dbimp.h)
>
> When I run with dbd::mysql (from 3.0002_4) it fails.
> When I turn all comparisons of MYSQL_VERSION_ID >=
> SERVER_PREPARE_VERSION around so it is < it works.
> Can someone tell my if dbd_st_execute is supposed to call
> mysql_st_internal_execute41 for versions of MySQL
> 40103 and lower or the opposite way around. I suspect it should be:
>
> if MYSQL_VERSION_ID < SERVER_PREPARE_VERSION
> use mysql_st_internal_execute41
>
> because other places in the code do things like:
>
> #if MYSQL_VERSION_ID < SERVER_PREPARE_VERSION if
> (mysql_real_query(&imp_dbh->mysql, "COMMIT", 6))
> #else
> if (mysql_commit(&imp_dbh->mysql))
> #endif
>
> because functions like mysql_commit were introduced in 4.1
>
> I'd greatly appreciate any help here as I'm desparately trying to make
> this work and trying very hard to feedback problems and fixes to
> DBD::mysql.
>
> Martin
>
>

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_IDand SERVER_PREPARE_VERSION

am 08.04.2006 01:49:05 von patg

Re: Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_IDand SERVER_PREPARE_VERSION

am 08.04.2006 09:51:39 von Martin.Evans

Patrick Galbraith wrote:
> Martin,
>
> Thanks for the info. Do you have a script that does this?
> mysql_st_execute41 should be called if mysql supports prepared
> statements, that is, >= SERVER_PREPARE_VERSION. I'm a bit suprised it
> works, but I think I have code that catches it even if it doesn't
> support prepared statements, so mysql_st_execute41 might have better
> handling, even for versions < 4.1. Please send whatever script you have
> to reproduce this. I'd like to see why it works where it shouldn't and
> where it doesn't where it should.
>
> Kind regards,
>
> Patrick

Patrick,

I posted the following patch for a test case to dbi-users list:

http://www.nntp.perl.org/group/perl.dbi.users/28909

Original posting and followups:

http://www.nntp.perl.org/group/perl.dbi.users/28896
http://www.nntp.perl.org/group/perl.dbi.users/28908

Martin

> Martin J. Evans wrote:
>
>> Hi,
>>
>> I could really do with a little assistance form the dbd::mysql
>> maintainers or authors please.
>>
>> I am investigating the issue I reported here with execute_array or all
>> executes failing after one execute fails.
>>
>> i.e.
>> create table test (a int primary key)
>> prepare(insert into test values(?)
>> execute(1) - OK
>> execute(2) - OK
>> execute(1) - fails but expected
>> execute(3) - fails but row inserted and not expected to fail
>>
>> It appears this has something to do with whether MYSQL_VERSION_ID is
>> <= SERVER_PREPARE_VERSION.
>>
>> My myql is 50015 and my client lib is also 50015 - as client and
>> server are on the same machine.
>> SERVER_PREPARE_VERSION is 40103 (in dbimp.h)
>>
>> When I run with dbd::mysql (from 3.0002_4) it fails.
>> When I turn all comparisons of MYSQL_VERSION_ID >=
>> SERVER_PREPARE_VERSION around so it is < it works.
>> Can someone tell my if dbd_st_execute is supposed to call
>> mysql_st_internal_execute41 for versions of MySQL
>> 40103 and lower or the opposite way around. I suspect it should be:
>>
>> if MYSQL_VERSION_ID < SERVER_PREPARE_VERSION
>> use mysql_st_internal_execute41
>>
>> because other places in the code do things like:
>>
>> #if MYSQL_VERSION_ID < SERVER_PREPARE_VERSION if
>> (mysql_real_query(&imp_dbh->mysql, "COMMIT", 6))
>> #else
>> if (mysql_commit(&imp_dbh->mysql))
>> #endif
>>
>> because functions like mysql_commit were introduced in 4.1
>>
>> I'd greatly appreciate any help here as I'm desparately trying to make
>> this work and trying very hard to feedback problems and fixes to
>> DBD::mysql.
>>
>> Martin
>>
>>
>
>

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_IDand SERVER_PREPARE_VERSION

am 08.04.2006 09:51:39 von Martin.Evans

RE: Help required from dbd::mysql maintainers/authors re MYSQL_VERSION_ID and SERVER_PREPARE_VERSION

am 08.04.2006 11:22:46 von Matthew.Simcox

Hi,

I'm using DBI with oracle 9i drivers.I have a script that opens a =
database handle $dbh and creates a table. A short while later I run an =
oracle stored procedure that ends up populating this table with schema =
statistics. This all works fine, but I noticed after some testing that =
when you have a look at the table creation script that is run by the =
oracle procedure "dbms_stats.create_stat_table(user, 'STAT_TAB', null)" =
the script contains thousands of insert statements as well as the table =
creation statement.

If I run the commands separately in TOAD I don't see this?

My guess is that I'll have to disconnect following the table creation =
statement and reconnect for the other commands, but this doesn't seem =
the right behaviour to me. I've set AutoCommit =3D> 1, but this made no =
difference.

Does anyone have any ideas how to avoid this, as it would appear a ddl =
statement is becoming mixed with a dml statement.

Thanks,

Matt

Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.