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 it want to
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 do if you use
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
old API.
Fine
On Thu, 24 Jul 2014 23:30:15 +0300, Vlad Khorsun
hv...@users.sourceforge.net 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
On Thu, 24 Jul 2014 23:08:56 -0300, Jim Starkey j...@jimstarkey.net
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
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 CURRENT OF,
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 Fri, 25 Jul 2014 12:49:37 +0400, Alex Peshkoff peshk...@mail.ru
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,
That may have been what you meant, but it wasn't what you said.
On Jul 25, 2014, at 3:37 AM, Mark Rotteveel m...@lawinegevaar.nl wrote:
On Thu, 24 Jul 2014 23:08:56 -0300, Jim Starkey j...@jimstarkey.net
wrote:
No, it supported multiple active statements since Groton Database
Systems
On Fri, 25 Jul 2014 07:33:48 -0300, Jim Starkey j...@jimstarkey.net
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 ?
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.e.
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
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: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 effect as
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 WHERE
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 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
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 works in
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 directly related
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
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 the
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,
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
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 CURRENT
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 statement ?
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 is
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 hv...@users.sourceforge.net wrote:
On 24-7-2014 19:27, Vlad Khorsun wrote:
As far
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
29 matches
Mail list logo
