Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems may happen when issuing DDL commands in the same transaction after CREATE COLLATION was issued [CORE3056] #3436

Closed
firebird-automations opened this issue Jun 18, 2010 · 11 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @asfernandes

Relate to CORE2826
Is related to QA553
Relate to CORE4425

Test case adapted from Vlad's comment in CORE2826:
---------------
CREATE COLLATION UNICODE_NOPAD FOR UTF8 FROM UNICODE NO PAD;
--COMMIT; -- (1)

RECREATE TABLE tst1_nopad (
k1 VARCHAR(3) COLLATE UNICODE_NOPAD,
k2 INT,
k3 CHAR(1) COLLATE UNICODE_NOPAD,
PRIMARY KEY (k1, k2, k3)
);
COMMIT;

SHOW TABLE tst1_nopad;
---------------

Note, without COMMIT at point (1), fields of tst1_nopad will have collate UTF8!

Also, multiple CREATE COLLATION for the same charset raises unique violation error.

Commits: 08bbc59

====== Test Details ======

1. Results are identical on: LI-T3.0.0.31827 (64 bit) and WI-T3.0.0.31827 (32 bit).
2. Despite of ticket issue that it was fixed only in 3.0, following script works OK on also on 2.5
(tested on WI-V2.5.5.26861; differences are only in stderr).
3. #⁠#⁠ TODO #⁠#⁠#⁠
Uncomment lines "--,constraint test_pk1 primary key" after CORE4783 will be fixed, and add
statement 'alter table drop constraint <PK>" before each DROP TABLE statements.

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

Link: This issue relate to CORE2826 [ CORE2826 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

summary: Problems may happen when issuing DDL commands in the same transaction after issue CREATE COLLATION => Fixed CORE3056 - Problems may happen when issuing DDL commands in the same transaction after CREATE COLLATION was issued

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: Fixed CORE3056 - Problems may happen when issuing DDL commands in the same transaction after CREATE COLLATION was issued => Problems may happen when issuing DDL commands in the same transaction after CREATE COLLATION was issued

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA553 [ QA553 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

Link: This issue relate to CORE4425 [ CORE4425 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: Done with caveats

Test Details: 1. Results are identical on: LI-T3.0.0.31827 (64 bit) and WI-T3.0.0.31827 (32 bit).
2. Despite of ticket issue that it was fixed only in 3.0, following script works OK on also oon 2.5
(tested on WI-V2.5.5.26861; differences are only in stderr).
3. #⁠#⁠ TODO #⁠#⁠#⁠
Uncomment lines "--,constraint test_pk1 primary key" after CORE4783 will be fixed, and add
statement 'alter table drop constraint <PK>" before each DROP TABLE statements.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

Test Details: 1. Results are identical on: LI-T3.0.0.31827 (64 bit) and WI-T3.0.0.31827 (32 bit).
2. Despite of ticket issue that it was fixed only in 3.0, following script works OK on also oon 2.5
(tested on WI-V2.5.5.26861; differences are only in stderr).
3. #⁠#⁠ TODO #⁠#⁠#⁠
Uncomment lines "--,constraint test_pk1 primary key" after CORE4783 will be fixed, and add
statement 'alter table drop constraint <PK>" before each DROP TABLE statements.

=>

1. Results are identical on: LI-T3.0.0.31827 (64 bit) and WI-T3.0.0.31827 (32 bit).
2. Despite of ticket issue that it was fixed only in 3.0, following script works OK on also on 2.5
(tested on WI-V2.5.5.26861; differences are only in stderr).
3. #⁠#⁠ TODO #⁠#⁠#⁠
Uncomment lines "--,constraint test_pk1 primary key" after CORE4783 will be fixed, and add
statement 'alter table drop constraint <PK>" before each DROP TABLE statements.

@firebird-automations
Copy link
Collaborator Author

Commented by: @pcisar

Test created.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment