On 27-6-2014 19:25, Ann Harrison wrote:
On Jun 23, 2014, at 3:57 PM, Nikolay Samofatov
nikolay.samofa...@red-soft.biz wrote:
Some records for a join can be read before a transaction is committed, and
some after. Same with EXISTS. It can see different set of commits from the
one when
On 24-6-2014 17:53, Paul Beach wrote:
But, after reading MS-SQL's read committed isolation level, their
default behavior is the same as Firebird's. And, they introduced the
READ COMMITTED SNAPSHOT isolation level, which is at the statement
level, and that is what Nickolay is looking for. And,
On 24-6-2014 18:05, Dimitry Sibiryakov wrote:
24.06.2014 17:53, Paul Beach wrote:
we need to keep our default behaviour as is and
create a new isolation level that supports the cursor stability
in Read Committed that Nikolay wants.
I would rather vote for a TPB flag like
On 25-6-2014 15:21, Dimitry Sibiryakov wrote:
This is right only for those who set up READ COMMITTED transaction
isolation level
which is not default.
That is not true, READ_COMMITTED is the default in a lot of the Firebird
drivers (eg in Jaybird, Firebird .NET provider, fdb).
Mark
--
28.06.2014 11:01, Mark Rotteveel wrote:
If a cursor is open, and the SQL-transaction in which the cursor was
opened makes a significant change to SQL-data
At the first glance, this is what we called cursor stability and have
fixed in FB3. But in fact it covers other cases as well and I don't
On 28-6-2014 09:51, Dmitry Yemanov wrote:
28.06.2014 11:34, Mark Rotteveel wrote:
Looking at the SQL standard, sensitivity should really be a property of
the statement (or more correctly: its cursor), not of the transaction.
True, but having all cursors insensitive by default per the given
On 28-6-2014 09:49, Dmitry Yemanov wrote:
28.06.2014 11:01, Mark Rotteveel wrote:
If a cursor is open, and the SQL-transaction in which the cursor was
opened makes a significant change to SQL-data
At the first glance, this is what we called cursor stability and have
fixed in FB3. But in
28.06.2014 11:54, Mark Rotteveel wrote:
As far as I understood, the cursor stability fix was about changes made
by the statement to its own data (eg an UPDATE or DELETE).
The fix was about changes made by statements located underneath the
cursor (e.g. for select + insert/update/delete inside,
28.06.2014 9:46, Mark Rotteveel wrote:
On 25-6-2014 15:21, Dimitry Sibiryakov wrote:
This is right only for those who set up READ COMMITTED transaction
isolation level
which is not default.
That is not true, READ_COMMITTED is the default in a lot of the Firebird
drivers (eg in
I am working on replacing the protocol implementation, and now I am
running into a 'problem' with parsing the status vector (or actually
with the result of that parse).
Currently I treat each isc_arg_gds and isc_arg_warning as a separate
exception that is chained to the previous exception, but
On 28-6-2014 10:36, Dimitry Sibiryakov wrote:
28.06.2014 9:46, Mark Rotteveel wrote:
On 25-6-2014 15:21, Dimitry Sibiryakov wrote:
This is right only for those who set up READ COMMITTED transaction
isolation level
which is not default.
That is not true, READ_COMMITTED is the default
28.06.2014 12:47, Mark Rotteveel wrote:
But as a datapoint, PostgreSQL does this:
Read Committed is the default isolation level in PostgreSQL. When a
transaction uses this isolation level, a SELECT query (without a FOR
UPDATE/SHARE clause) sees only data committed before the query began; it
You shouldn't have to care. The status vector is a well defined, self
describing data structure. A transmission protocol should pass it, not
interpret it. If you have to get involved in the semantics, you're either
doing something wrong (or somebody screwed up the architecture).
That said, the
On 28-6-2014 11:14, James Starkey wrote:
You shouldn't have to care. The status vector is a well defined, self
describing data structure. A transmission protocol should pass it, not
interpret it. If you have to get involved in the semantics, you're
either doing something wrong (or somebody
28.06.2014 12:38, Mark Rotteveel wrote:
I am working on replacing the protocol implementation, and now I am
running into a 'problem' with parsing the status vector (or actually
with the result of that parse).
Currently I treat each isc_arg_gds and isc_arg_warning as a separate
exception
28.06.2014 11:14, James Starkey wrote:
That said, the philosophy is that the frst code is primary -- something an
application
programmer can make part of his application logic.
What logic can be built on isc_dsql_error - something happened in DSQL
which is used
to be a primary code for
28.06.2014 10:43, Mark Rotteveel wrote:
How about no. READ COMITTED is the default for a lot of other database
drivers for other DBMS as well, and usually matches the expectations of
users (which includes the occurrence of non-repeatable reads and phantom
reads).
Who cares about other
DSQL was originally a client side facility that used the public DB2 SQL API
for the lack of any other standard. The DB2 API returned only SQL codes.
Borland turned DSQL from a client facillity to a server facility. In the
process, they integrated the DB2-like API into the larger Interbase API,
after fb_shutdown(), end-of-process cleanup should not do anything
--
Key: CORE-4475
URL: http://tracker.firebirdsql.org/browse/CORE-4475
Project: Firebird Core
Issue Type: Bug
19 matches
Mail list logo
