Event delivery could be missed when local (XNET) protocol is used
-
Key: CORE-6488
URL: http://tracker.firebirdsql.org/browse/CORE-6488
Project: Firebird Core
Issue Type: Bug
On 2/15/21 7:39 PM, Mark Rotteveel wrote:
On 15-02-2021 16:21, Alex Peshkoff via Firebird-devel wrote:
On 2/14/21 4:01 PM, Mark Rotteveel wrote:
For documentation purposes, I was wondering if this was intended
behaviour, both the ability to position beyond the bounds of the
result set using
On 15-02-2021 16:21, Alex Peshkoff via Firebird-devel wrote:
On 2/14/21 4:01 PM, Mark Rotteveel wrote:
For documentation purposes, I was wondering if this was intended
behaviour, both the ability to position beyond the bounds of the
result set using ABSOLUTE, and the remembering of the actual
FETCH ABSOLUTE and RELATIVE beyond bounds of cursor should always position
immediately before-first or after-last
-
Key: CORE-6487
URL:
On 15-02-2021 16:45, Dimitry Sibiryakov wrote:
15.02.2021 16:21, Alex Peshkoff via Firebird-devel wrote:
Trying to position in non-existent place should better raise error.
According to ODBC (which is the most-established DB API) specs of
SQLFetchScroll() function fetching beyond record
On 15-02-2021 16:21, Alex Peshkoff via Firebird-devel wrote:
On 2/14/21 4:01 PM, Mark Rotteveel wrote:
For documentation purposes, I was wondering if this was intended
behaviour, both the ability to position beyond the bounds of the
result set using ABSOLUTE, and the remembering of the actual
15.02.2021 16:21, Alex Peshkoff via Firebird-devel wrote:
Trying to position in non-existent place should better raise error.
According to ODBC (which is the most-established DB API) specs of SQLFetchScroll()
function fetching beyond record set must end up to fixed "before start"/"after
On 2/14/21 4:01 PM, Mark Rotteveel wrote:
For documentation purposes, I was wondering if this was intended
behaviour, both the ability to position beyond the bounds of the
result set using ABSOLUTE, and the remembering of the actual position
for subsequent fetches.
Or if this is just an
15.02.2021 12:47, Mark Rotteveel wrote:
The Firebird 2.5 Language Reference has the following remark in its description
of CONTAINING[1]:
"""
When CONTAINING is used in the search conditions of DML queries, the Firebird optimizer can use an index on the searched column, if
a suitable one
On 15/02/2021 07:47, Mark Rotteveel wrote:
> The Firebird 2.5 Language Reference has the following remark in its
> description of CONTAINING[1]:
>
> """
> When CONTAINING is used in the search conditions of DML queries, the
> Firebird optimizer can use an index on the searched column, if a
>
The Firebird 2.5 Language Reference has the following remark in its
description of CONTAINING[1]:
"""
When CONTAINING is used in the search conditions of DML queries, the
Firebird optimizer can use an index on the searched column, if a
suitable one exists.
"""
Is that remark correct? How I
11 matches
Mail list logo