Hi!
I just noticed that I receive better error messages with DBD-ODBC 0.28
and DBI 1.14 compared to DBD-ODBC 1.00 and DBI 1.32
With the old versions I get this generated by $sth-execute():
DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver][SQL
Server]Subquery returned more than
Roger Perttu wrote:
Hi!
When I destroy my objects I would like to know if there are
uncommitted transactions. There shouldn't be any but I would like to
know. Given only a DBI database handle, is it possible to find out if
there are uncommitted transactions? If not, is there anything inside
Hi!
When I destroy my objects I would like to know if there are uncommitted
transactions. There shouldn't be any but I would like to know. Given
only a DBI database handle, is it possible to find out if there are
uncommitted transactions? If not, is there anything inside DBD-ODBC that
I could
and the pure
Perl part of it probably never regains control.
Anyway, SET LOCK_TIMEOUT works for me and the program dies. I realize
that I probably should *always* use SET LOCK_TIMEOUT, at least when
autocommit is off.
-Original Message-
From: Roger Perttu [mailto:[EMAIL PROTECTED]]
Sent
Brien Pirkle wrote:
How can I execute a SQL Server stored proc from my Perl script? The Cheeta
book (DBD::ODBC Driver pg 296) suggests using the following ODBC escape
sequence:
{call procedure1_name}
Fine. But what's the rest of the syntax?
From BOL:
The ODBC CALL escape sequence for
Brien Pirkle wrote:
Jeff,
So, assuming sp_foo takes no paramters, my whole script could be:
#
use DBI;
my $dbh = DBI-connect('DBI:ODBC:OSTDB', 'user', 'password')
or die Couldn't connect to database: . DBI-errstr;
{call sp_foo}
#More like this:
my
Dave Thorn wrote:
On Tue, Oct 22, 2002 at 09:54:03AM -0400, Jeff Urlwin wrote:
[SQLFetch()]
The first time through, we see (snipped from trace below)
fetch col#4 SC_VALUE datalen=0 displ=256
fetch col#4 SC_VALUE datalen=19 displ=256
The second time through, I see:
fetch
right
click and select Properties I don't see the Version tab that you usually
see with dll's.
I don't have the tools to build from source.
Martin
On 16-Oct-2002 Roger Perttu wrote:
[EMAIL PROTECTED] wrote:
I have snipped ALL previous discussion on this as I am finding it almost
Jeff Urlwin wrote:
I rewrote my program using JScript and the OLEDB provider for ODBC. But
that didn't result in any use of SET FMTONLY... so I assume this is
something that Jeff is triggering in his code.
Not directly -- only via ODBC calls.
Jeff
I'm beginning to suspect that my
Waldemar Zurowski wrote:
On Tue, 15 Oct 2002 12:56:36 +0100 (BST)
[EMAIL PROTECTED] wrote:
I don't see any of this being the fault of DBD::ODBC. There are other
issues with the MS SQL Server ODBC driver and procedures (specifically
cursors) you might want to be aware of - search microsoft's
or something. I know I found a very special condition
but it would be nice if it was fixed. Now that I know more I'm not
saying it's a true bug in DBI, but rather a lack of a workaround for a
problem in MS code.
On some of your other comments:
On 16-Oct-2002 Roger Perttu wrote:
I recall
somewere)
The trace is the result of _one_ call from Perl. This might be a bug in
ODBC, I don't know.
It would be nice if someone else would test this.
/Roger P
-Original Message-
From: Roger Perttu [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 8:47 AM
To: [EMAIL PROTECTED
Thanks, Martin.
I've found similar information in BOL and MSDN. I'm _not_ an expert on
ODBC so when I see the trace in SQL Profiler I don't know if the
statements are generated by DBD-ODBC or implicitly by the ODBC driver.
A note to Tim if he reads this:
It would be _very_ nice if it would be
Thomas A. Lowery wrote:
Roger,
My work with DBD-ADO and stored procedures is very limited. If you could
provide me with a few (at least one) complete example that generates this
error, fixing it would be much easier. Also, I haven't a lot of time to
work on DBD-ADO.
I've just started to experiment with DBD-ADO 2.5. I'm trying to figure
out if it's a viable option to DBD-ODBC.
I've got this snippet of code that doesn't seem to work with DBD-ADO:
my $dbh = newDbh();
my $sth = $dbh-prepare({call testPrc(?)});
$sth-bind_param(1, 10, { TYPE = 4
Sorry for my last post. I managed to attach a much to big trace (several
runs of the program).
Roger Perttu wrote:
I've just started to experiment with DBD-ADO 2.5. I'm trying to figure
out if it's a viable option to DBD-ODBC.
I've got this snippet of code that doesn't seem to work
Hi all,
Where can I find a PPM package for DBD-ADO 2.5?
It's not in any of the following:
XMLPROJ: http://www.xmlproj.com/PPM/
THEORYX5: http://theoryx5.uwinnipeg.ca/ppmpackages/
ActiveState Package Repository:
http://ppm.ActiveState.com/cgibin/PPM/ppmserver.pl?urn:/PPMServer
but it didn't.
Finally I changed my test script to use two parameters and the procedure is now called
with both parameters wrong.
/Roger P
Original Message
Subject: Re: Bug in DBD-ODBC 0.45_16
Date: Thu, 03 Oct 2002 18:01:20 +0200
From: Roger Perttu [EMAIL PROTECTED]
Organization: Easit AB
Jeff,
I've been busy but finally managed to test the new version. It still
fails my test.
Jeff Urlwin wrote:
Roger,
I've finally had a chance to look at this (going through my queue of issues
questions). What I can see is the following:
- No result columns are being returned
In my
SQL-37000 = Syntax error or access violation
In SQL Server (yes I know you use Access) you don't update timestamps,
they are updated for you.
Try to print out the statement then use some other tool (Access?) to run
the query.
/Roger P
[EMAIL PROTECTED] wrote:
Dear all,
Here is the code
Tim Bunce wrote:
On Tue, Sep 10, 2002 at 01:49:35PM +0200, Roger Perttu wrote:
Tim Bunce wrote:
On Wed, Sep 04, 2002 at 09:58:35AM -0500, Paul DuBois wrote:
At 9:50 -0500 9/4/02, David Dooling wrote:
For security reasons, wouldn't you want to know what statements
Bodo Eing wrote:
Roger Perttu wrote:
Hi everyone,
I have a problem with DBI. If I have no control of the SQL statement
being run, how do I know if it's safe to call fetchrow_hashref()?
my $sth = $dbh-prepare($someUnknownStatement);
$sth-execute();
# Safe to call fetchrow_hashref
Ronald J Kimball wrote:
On Wed, Sep 04, 2002 at 02:27:23PM +0200, Roger Perttu wrote:
No, your suggestion won't work for me. I have absolutely no control of
the query. Stored procedures with multiple or no result sets will be
common. If I chose to use eval it will be rather painful to use
Felix Geerinckx wrote:
on Wed, 04 Sep 2002 12:27:23 GMT, [EMAIL PROTECTED] (Roger
Perttu) wrote:
I have absolutely no control of the query.
So a simple 'DROP DATABASE' would also be acceptable ;-)
Yes, The user might want to copy data from a production database to a
reporting
.
Impossible (stored procedures might do anything)
On Wed, Sep 04, 2002 at 04:16:14PM +0200, Roger Perttu wrote:
I store the result for later use in another query.
How do you parse the SQL to know what to do with it?
I don't parse it.
If this is the (pseudo) input to my program
mrtlc wrote:
I want to pull some data down from a Teradata database to a Win2k/NT server.
I use DBI or Win32::ODBC, a system DSN (teradata1) is created.
use DBI;
use DBD::ODBC;
my $dbh = DBI-connect(DBI:ODBC:teradata1, uname, moo);
...
or
use Win32::ODBC;
$data = new Win32::ODBC(DSN =
First, big thanks to Jeff Urlwin for developing DBD::ODBC, (for me) DBI
would be useless without it.
I'm using SQL Server and DBD::ODBC 0.41 (because that's what I can get
by ppm) I've read the change log and am wondering if the 0.45 release is
better (more stable) than 0.41. I could write
Jeff Urlwin wrote:
Yes, from around .3x, but for the best support so far and, what I believe to
be the most bug free, try the latest (0.45_14). In that archive are some
examples, both in t/20SqlServer.t and mytest/*.
If there are no bugs reported in that version, I'm going to re-release it as
28 matches
Mail list logo
