This is not the correct list for this question - this list is for Perl DBI
users. Try http://lists.cpan.org/showlist.cgi?name=beginners.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
On 25-Jul-2006 Amar P. Singh wrote:
Hi All,
This is my first email to the group and I
Hi,
I have no knowledge of the DBIx::ContextualFetch module, and so have no
idea whether upgrading DBD::Sybase could fix the problem.
The issue could be related to multiple-result sets, or to some other
Sybase-specific issue that isn't handled properly by DBIx::ContextualFetch,
or maybe something
Ok now coming to the problem. Can someone explain to me that what this
script is doing. I want to know the meaning of all the lines in the
script.
$val = defined $val ? $val : null;
$val =~ s/\'/$ x 2/eg; # double pad single
quote character '
I suspect that I know the answer already but ..
does DBD::mysql (or the MySQL API for that matter) support random
access to BLOB types ? i.e. the ability to select/insert
a BLOB via a serious of small queries, as opposed to the
memory intensive approach of selecting/inserting the total
contents
does DBD::mysql (or the MySQL API for that matter) support random
access to BLOB types ? i.e. the ability to select/insert
a BLOB via a serious of small queries, as opposed to the
memory intensive approach of selecting/inserting the total
contents of the column in one query.
It's unlikely that
This part of DBIx::ContextualFetch is just a statement handle subclass.
It's trying to call $sth-SUPER::execute() which is where the error is
occurring. I suppose it could be something about DBI instead of
DBD::Sybase, but I use DBIx::ContextualFetch with Oracle and I've never
seen the error.
On 25-Jul-2006 Stephen Collyer wrote:
I suspect that I know the answer already but ..
does DBD::mysql (or the MySQL API for that matter) support random
access to BLOB types ? i.e. the ability to select/insert
a BLOB via a serious of small queries, as opposed to the
memory intensive
John,
When you say named parameter binding is not supported, are you talking about
*all* named parameters, or just for array operations? We use named
parameters (e.g. :cust_id) extensively because it is more readable, position
independent, and if you are using the same parameter more than once
On Tue, 2006-07-25 at 09:44 -0400, Garrett, Philip (MAN-Corporate)
wrote:
This part of DBIx::ContextualFetch is just a statement handle subclass.
It's trying to call $sth-SUPER::execute() which is where the error is
occurring. I suppose it could be something about DBI instead of
DBD::Sybase,
I know this is one of those how long is a piece of string questions but
I cannot see any difference using prepare_cached with a remote mysql or
oracle database. I have code which does inserts/updates/selects - around
20 - 30 different pieces of SQL and most of them are run between a 100
and 1000
When you say named parameter binding is not supported, are you talking
about
*all* named parameters, or just for array operations?
Ohh god no!!
Just when using the execute_array(); command like this
my $sth = $dbh-prepare(INSERT INTO DETAILS ( ID, P_ID, DATE_ENTRY) VALUES
(:p1,:p2,:p3)) ;
To follow up on this in case others encounter a similar problem, I
statically linked libclntsh.so into Oracle.so like so:
ld -shared -L/usr/local/lib libclntsh.so Oracle.o dbdimp.o oci8.o -o
blib/arch/auto/DBD/Oracle/Oracle.so
Using that, I can execute SQL statments under mod_perl without
I know nothing about MySQL, but I benchmarked prepare vs prepare_cached
in Oracle many moons ago, and saw no great difference, which is actually
what I expected. In theory, the main savings is avoiding the repeated
cost of the database parsing and prepping the statement, but Oracle
does its own
13 matches
Mail list logo
