On 27-Jun-2005 Daniel Kasak wrote:
> Jeff Urlwin wrote:
>
>>Please read DBD::ODBC pod. Specifically the section on the odbc_cursortype.
>>
>>Jeff
>>
>>
> I just added odbc_cursortype=> DBI::SQL_CURSOR_DYNAMIC to our
> connection string, and that didn't help things at all.
> Martin J. Evans
Jeff Urlwin wrote:
>Please read DBD::ODBC pod. Specifically the section on the odbc_cursortype.
>
>Jeff
>
>
I just added odbc_cursortype=> DBI::SQL_CURSOR_DYNAMIC to our
connection string, and that didn't help things at all.
Martin J. Evans ( see other post on topic ) says that this won't w
Martin J. Evans wrote:
>>Just tried that. Doesn't seem to have any effect on my system. Here's
>>the line I added right after create $dbh :
>>$dbh->{odbc_SQL_ROWSET_SIZE} = 2;
>>
>>
>
>Didn't you say something about using FreeTDS? If so that hack might not work
>for FreeTDS. Against MS SQL Ser
ook a Perl-Gtk2 app which has been running fine, and
> >>substituted the
> >>old DBD::Sybase connection with the DBD::ODBC one, and then
> >>discovered I
> >>could only run one query on SQL Server, and then all
> >>subsequent queries
> >>gave:
Daniel,
On 22-Jun-2005 Daniel Kasak wrote:
> Martin J. Evans wrote:
>
>>As far as I am aware this is a limitation of the TDS protocol used and
>>your example code will not work unless you force a server-side cursor (see
>>DBD::ODBC pod and look for odbc_SQL_ROWSET_SIZE but I warn you that you
>>r
Martin J. Evans wrote:
>As far as I am aware this is a limitation of the TDS protocol used and
>your example code will not work unless you force a server-side cursor (see
>DBD::ODBC pod and look for odbc_SQL_ROWSET_SIZE but I warn you that you really
>will need to close everything i.e. force SQLFr
Terence,
I could be wrong but from what little I remember from TDS I think
that unless you enable a server-side cursor, once you start retrieving
data from the server you have no choice but to keep reading it until
it is exhausted - this is why SQL Server ODBC driver only supports
1 active statem
Hi,
You should only have to clear the statement if you are fetching a single
row or fetching into a set variables. This will happen even if the
result set on the backend contains only one record. If you are fetching
row by row in a loop, fetching one more time beyond the last record
should c
has been running fine, and
>>>substituted the
>>>old DBD::Sybase connection with the DBD::ODBC one, and then
>>>discovered I
>>>could only run one query on SQL Server, and then all
>>>subsequent queries
>>>gave:
>>>
>>>
ybase connection with the DBD::ODBC one, and then
>>discovered I
>>could only run one query on SQL Server, and then all
>>subsequent queries
>>gave:
>>
>>DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL
>>Server]Attempt to
>>initiate a new
, and then
> discovered I
> could only run one query on SQL Server, and then all
> subsequent queries
> gave:
>
> DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL
> Server]Attempt to
> initiate a new SQL Server operation with results pending.
> (SQL-07005
r, and then all subsequent queries
gave:
DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL Server]Attempt to
initiate a new SQL Server operation with results pending.
(SQL-07005)(DBD: st_execute/SQLExecute err=-1)
Damn!
So I started going through my code and adding $sth->finish after
12 matches
Mail list logo
