On 07/28/14 14:37, Adriano dos Santos Fernandes wrote:
> On 28/07/2014 04:52, Alex Peshkoff wrote:
>> On 07/24/14 18:05, Adriano dos Santos Fernandes wrote:
>>> On 24/07/2014 10:59, Alex Peshkoff wrote:
Also ugly.
I would better like to support setCursorName(NULL) in order to emulate
On 28/07/2014 04:52, Alex Peshkoff wrote:
> On 07/24/14 18:05, Adriano dos Santos Fernandes wrote:
>> On 24/07/2014 10:59, Alex Peshkoff wrote:
>>> Also ugly.
>>> I would better like to support setCursorName(NULL) in order to emulate
>>> old API.
>>>
>>>
>> Fine for me.
> One more problem - what to
On 07/24/14 18:05, Adriano dos Santos Fernandes wrote:
> On 24/07/2014 10:59, Alex Peshkoff wrote:
>> Also ugly.
>> I would better like to support setCursorName(NULL) in order to emulate
>> old API.
>>
>>
> Fine for me.
One more problem - what to do if you use IAttachment::openCursor() and
after
On Fri, 25 Jul 2014 07:33:48 -0300, Jim Starkey
wrote:
> That may have been what you meant, but it wasn't what you said.
Context is everything, and I'll repeat the context again:
>>What about more than one simultaneously active result set produced
>>by the same statement ?
>
> As far as
That may have been what you meant, but it wasn't what you said.
> On Jul 25, 2014, at 3:37 AM, Mark Rotteveel wrote:
>
> On Thu, 24 Jul 2014 23:08:56 -0300, Jim Starkey
> wrote:
>> No, it supported multiple active statements since Groton Database
> Systems
>> time. And before that, Rdb/ELN.
On Fri, 25 Jul 2014 12:49:37 +0400, Alex Peshkoff
wrote:
> On 07/25/14 03:23, Adriano dos Santos Fernandes wrote:
>> Em 24-07-2014 17:30, Vlad Khorsun escreveu:
>>
>>> So, currently we really have no way to call
>>> IStatement::openCursor...
>>>
>> BTW, isn't openCursor a bad name too, s
On 07/25/14 03:23, Adriano dos Santos Fernandes wrote:
> Em 24-07-2014 17:30, Vlad Khorsun escreveu:
>
>> So, currently we really have no way to call IStatement::openCursor...
>>
> BTW, isn't openCursor a bad name too, since it actually executes (not
> only "open") the query, and it returns a
On 07/24/14 20:49, Dimitry Sibiryakov wrote:
> 24.07.2014 18:39, Mark Rotteveel wrote:
>> A cursor name should remain set for the lifetime of the statement,
>> unless it is explicitly set to a different value.
> Ok. If there is two statements: one with cursor name and other using
> WHERE CURRE
On Thu, 24 Jul 2014 23:08:56 -0300, Jim Starkey
wrote:
> No, it supported multiple active statements since Groton Database
Systems
> time. And before that, Rdb/ELN.
>
> Why do people make up "facts" to bolster losing arguments?
You are responding to Vlad, but given your other e-mail I am assumi
On Thu, 24 Jul 2014 23:30:15 +0300, "Vlad Khorsun"
wrote:
>> and most implementations I know with multiple result sets either
require
>> or allow only one result set open at a time (and if they allow multiple
>> result sets open, that is usually achieved by fully reading and
>> detaching previo
No, it supported multiple active statements since Groton Database Systems time.
And before that, Rdb/ELN.
Why do people make up "facts" to bolster losing arguments?
On Jul 24, 2014, at 5:30 PM, "Vlad Khorsun" wrote:
>> On 24-7-2014 19:27, Vlad Khorsun wrote:
As far as I understand it,
Em 24-07-2014 17:30, Vlad Khorsun escreveu:
> So, currently we really have no way to call IStatement::openCursor...
>
BTW, isn't openCursor a bad name too, since it actually executes (not
only "open") the query, and it returns a IResultSet (not ICursor)?
I prefer the JDBC name, as our API i
> On 24-7-2014 19:27, Vlad Khorsun wrote:
>>> As far as I understand it, you can't have an IResultSet unless the
>>> result set is open, so setting the cursor name on an IResultSet is not
>>> very logical.
>>
>> What about more than one simultaneously active result set produced by
>> the same
On 24-7-2014 18:49, Dimitry Sibiryakov wrote:
> 24.07.2014 18:39, Mark Rotteveel wrote:
>> A cursor name should remain set for the lifetime of the statement,
>> unless it is explicitly set to a different value.
>
> Ok. If there is two statements: one with cursor name and other using
> WHERE CU
On 24-7-2014 19:35, Dimitry Sibiryakov wrote:
> 24.07.2014 18:59, Mark Rotteveel wrote:
>> What is your point? That problem already exists with how it currently
>> works. The cursor referenced should be checked at execute time, not at
>> prepare time.
>
> In this case what's wrong with name bou
24.07.2014 18:59, Mark Rotteveel wrote:
> What is your point? That problem already exists with how it currently
> works. The cursor referenced should be checked at execute time, not at
> prepare time.
In this case what's wrong with name bound to result set?
--
WBR, SD.
---
On 24-7-2014 18:49, Dimitry Sibiryakov wrote:
> 24.07.2014 18:39, Mark Rotteveel wrote:
>> A cursor name should remain set for the lifetime of the statement,
>> unless it is explicitly set to a different value.
>
> Ok. If there is two statements: one with cursor name and other using
> WHERE CU
24.07.2014 18:39, Mark Rotteveel wrote:
> A cursor name should remain set for the lifetime of the statement,
> unless it is explicitly set to a different value.
Ok. If there is two statements: one with cursor name and other using WHERE
CURRENT OF,
what should happen is the first statement is
On 24-7-2014 15:38, Adriano dos Santos Fernandes wrote:
>> But what solution can we suggest? Move setCursorName back to IStatement
>> and blank it when cursor is closed?
>
> It's better than have setCursorName in IResultSet.
Neither are a good solution. setCursorName should be in IStatement, and
On 24-7-2014 12:30, Alex Peshkoff wrote:
> That move was not directly related with TCS fail. Originally setting
> cursor name remained in effect only for cursor life-time - i.e. after
> isc_dsql_free_statement with DSQL_close option cursor name was
> destroyed. If we set cursor name for statement,
On 23-7-2014 17:59, Adriano dos Santos Fernandes wrote:
> Hi!
>
> After I reported an TCS fail to Alex in January, he moved this method
> from IStatement to IResultSet.
>
> But I fail to understand. Not talking about implementation detail, but
> about interface.
>
> IMO makes no sense to first open
On 24/07/2014 10:59, Alex Peshkoff wrote:
> Also ugly.
> I would better like to support setCursorName(NULL) in order to emulate
> old API.
>
>
Fine for me.
Adriano
--
Want fast and easy access to all the code in your e
On 07/24/14 17:38, Adriano dos Santos Fernandes wrote:
> On 24/07/2014 07:30, Alex Peshkoff wrote:
>> On 07/23/14 19:59, Adriano dos Santos Fernandes wrote:
>>> Hi!
>>>
>>> After I reported an TCS fail to Alex in January, he moved this method
>>> from IStatement to IResultSet.
>> That move was not
24.07.2014 15:14, Dimitry Sibiryakov wrote:
>> I haven't tried. Did it work before?
>
> No.
And this is correct.
>> Not everybody is working with slow networks.
>
> Any network is slow for transferring one record per fetch. Embedded server
> shows this
> problem well. (Every SELECT in it wo
24.07.2014 15:38, Adriano dos Santos Fernandes wrote:
> Maybe a flag in the new API close method to use the old or the good
> behavior?
Tell me that this is a joke, please...
--
WBR, SD.
--
Want fast and easy acce
On 24/07/2014 07:30, Alex Peshkoff wrote:
> On 07/23/14 19:59, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> After I reported an TCS fail to Alex in January, he moved this method
>> from IStatement to IResultSet.
> That move was not directly related with TCS fail. Originally setting
> cursor na
24.07.2014 13:08, Dmitry Yemanov wrote:
> I haven't tried. Did it work before?
No.
> Not everybody is working with slow networks.
Any network is slow for transferring one record per fetch. Embedded server
shows this
problem well. (Every SELECT in it works in non-buffered mode.)
> Nope,
24.07.2014 14:54, Dimitry Sibiryakov wrote:
> Does it work without "FOR UPDATE" in SELECT now?
I haven't tried. Did it work before?
> Has "FOR UPDATE" clause stopped killing network peformance?
Not everybody is working with slow networks.
> Using RDB$DB_KEY for DML has the same effect as "WHER
24.07.2014 12:47, Dmitry Yemanov wrote:
> And also deprecate WHERE CURRENT OF in DSQL for being "useless"? Just
> because you don't use it?
Does it work without "FOR UPDATE" in SELECT now? Has "FOR UPDATE" clause
stopped kiling
network peformance?
Using RDB$DB_KEY for DML has the same effe
24.07.2014 14:37, Dimitry Sibiryakov wrote:
>
> In new API you can simply deprecate using named cursors. They are almost
> useless anyway.
And also deprecate WHERE CURRENT OF in DSQL for being "useless"? Just
because you don't use it?
Dmitry
--
24.07.2014 12:30, Alex Peshkoff wrote:
> IMHO in old API this is required. But what about new one?
In new API you can simply deprecate using named cursors. They are almost
useless anyway.
--
WBR, SD.
--
Want fast
On 07/23/14 19:59, Adriano dos Santos Fernandes wrote:
> Hi!
>
> After I reported an TCS fail to Alex in January, he moved this method
> from IStatement to IResultSet.
That move was not directly related with TCS fail. Originally setting
cursor name remained in effect only for cursor life-time - i
Hi!
After I reported an TCS fail to Alex in January, he moved this method
from IStatement to IResultSet.
But I fail to understand. Not talking about implementation detail, but
about interface.
IMO makes no sense to first open the cursor and then name it later.
We can have two prepared statement
33 matches
Mail list logo
