Magnus Hagander <[EMAIL PROTECTED]> writes:
> IIRC, the behavior of MSSQL will depend on the query plan. If it's a
> plan that requires doesn't require materialization at all, it won't
> figure it out until you get there.
... which is pretty much what we do, too.
regards,
Pit M. wrote:
>
>> It would have failed if you had run the cursor far enough to fetch one
>> of the bad rows.
>>
>> regards, tom lane
>>
> The difference is that in one case the query fails and in the other the
> FETCH command fails.
>
>
> Our problem is that if a query succeeds we u
It would have failed if you had run the cursor far enough to fetch one
of the bad rows.
regards, tom lane
The difference is that in one case the query fails and in the other the
FETCH command fails.
Our problem is that if a query succeeds we use a count(*) of that q
"Pit M." <[EMAIL PROTECTED]> writes:
> Following query fails in pgAdmin which is OK because the field PLZZ
> contains characters:
> select * from "PERSONEN" where (CAST("PERSONEN"."PLZZ" AS INTEGER) >=
> 7 );
> but if using the same query with a cursor ist works:
> START TRANSACTION;
> DE
Following query fails in pgAdmin which is OK because the field PLZZ
contains characters:
select * from "PERSONEN" where (CAST("PERSONEN"."PLZZ" AS INTEGER) >=
7 );
but if using the same query with a cursor ist works:
START TRANSACTION;
DECLARE c21112234 SCROLL CURSOR FOR select * from "
