-
-
Notifications
You must be signed in to change notification settings - Fork 212
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
Wrong resultset [CORE3052] #3432
Comments
Modified by: Attila Molnár (e_pluribus_unum)environment: Tested in differend hardwares and different Win => Tested in different hardwares (x32, x64), different OS (Win, Linux), different type (Classic, SuperServer) |
Modified by: Attila Molnár (e_pluribus_unum)description: CREATE TABLE tmp_test ( ALTER TABLE tmp_test ADD CONSTRAINT tmp_test_uk1 UNIQUE (m1, m2); INSERT INTO tmp_test (m1, m2, val) VALUES ('A', 'C1', 1); SELECT * SELECT * SELECT * SELECT * SELECT * All five works fine on 1.5, but on FB 2.0 the first two gives bad result. => CREATE TABLE tmp_test ( ALTER TABLE tmp_test ADD CONSTRAINT tmp_test_uk1 UNIQUE (m1, m2); INSERT INTO tmp_test (m1, m2, val) VALUES ('A', 'C1', 1); SELECT * SELECT * SELECT * SELECT * SELECT * On FB 1.5 (ODS 10.1) All five works fine. |
Commented by: @hvlad Confirmed. Key, used for search in the b-tree, is different than key, used when value was inserted into b-tree. This is true for PXW_HUNDC and two-segmens index and false for default collation or for single segment index (on M2 only). The search key is (i put bytes from every segment into separate line) : while the first key in index is : The code i can't completely understand is in LC_NARROW_string_to_key, /intl/lc_narrow.cpp line, 294 (per v2.5 sources) near : // ASF: If key_type == INTL_KEY_PARTIAL and the last CompressPair This function produced key of 0 bytes length for string 'C' Call stack : > fbintl.dll!LC_NARROW_string_to_key(texttype * obj=0x02be2dd4, unsigned short iInLen=1, const unsigned char * pInChar=0x02c17480, unsigned short iOutLen=4096, unsigned char * pOutChar=0x01df99a2, unsigned short key_type=1) Line 297 C++ Probably Adriano could explain it. |
Commented by: Attila Molnár (e_pluribus_unum) Hi! SELECT * So there is a workaround, BUT it is unacceptable that we rewrite every single sql conditions in our projects. |
Commented by: @hvlad This is bad workaround as it is equal to te.m2 LIKE '%' , see number of indexed reads ... |
Commented by: @asfernandes > This function produced key of 0 bytes length for string 'C' Vlad, this is correct, believe me. It's related to compressions (like "ch" that expands to different characters, but still starts with "c"). The bug here is CORE1188, as LIKE injects a STARTING WITH. |
Modified by: @asfernandes |
Modified by: @asfernandes |
Commented by: Attila Molnár (e_pluribus_unum) The related CORE1188 is open for 3 years, and not backported to 2.x. BTW, I can confim Adrianos state. After reading his "ch" example I tested special hungarian letters. It's related to special hungarian letters, which contains more than one character (cs, dz, dzs, gy, ly, ty, sz, zs). |
Commented by: Attila Molnár (e_pluribus_unum) Hi! Any news on this issue? |
Modified by: @asfernandesstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Alpha 1 [ 10331 ] assignee: Adriano dos Santos Fernandes [ asfernandes ] |
Commented by: Attila Molnár (e_pluribus_unum) Finally! Thank You! |
Commented by: @asfernandes The fix changes how some index keys are generated, so I don't think it can be backported without side effects. |
Commented by: @pcisar Test created. |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: Attila Molnár (e_pluribus_unum)
Relate to CORE1188
Depends on CORE1188
Is related to QA551
Votes: 2
CREATE TABLE tmp_test (
m1 xvar10n /* XVAR10N = VARCHAR(10) NOT NULL */,
m2 xvar10n /* XVAR10N = VARCHAR(10) NOT NULL */,
val xint /* XINT = INTEGER */
);
ALTER TABLE tmp_test ADD CONSTRAINT tmp_test_uk1 UNIQUE (m1, m2);
INSERT INTO tmp_test (m1, m2, val) VALUES ('A', 'C1', 1);
INSERT INTO tmp_test (m1, m2, val) VALUES ('A', 'C2', 2);
INSERT INTO tmp_test (m1, m2, val) VALUES ('A', 'D2', 3);
INSERT INTO tmp_test (m1, m2, val) VALUES ('A', 'M3', 3);
SELECT *
FROM tmp_test te
WHERE te.m1 = 'A' AND te.m2 LIKE 'C%'
--No line returned! (wrong), PLAN (TE INDEX (TMP_TEST_UK1))
SELECT *
FROM tmp_test te
WHERE te.m1 = 'A' AND te.m2 LIKE 'D%'
--No line returned! (wrong), PLAN (TE INDEX (TMP_TEST_UK1))
SELECT *
FROM tmp_test te
WHERE te.m1 = 'A' AND te.m2 LIKE 'M%'
--One line returned. (OK), PLAN (TE INDEX (TMP_TEST_UK1))
SELECT *
FROM tmp_test te
WHERE te.m1 = 'A' AND te.m2 LIKE '%C%'
--Two lines returned. (OK), PLAN (TE INDEX (TMP_TEST_UK1))
SELECT *
FROM tmp_test te
WHERE te.m2 LIKE 'C%'
-- Two lines returned. (OK), PLAN (TE NATURAL)
On FB 1.5 (ODS 10.1) All five works fine.
On FB 2.0 (ODS 10.1) All five works fine.
On FB 2.0 (ODS 11.0) The first two gives bad result.
The char set is WIN1250 and the collate is PXW_HUNDC.
Commits: c1c5d2b 57ddc9e FirebirdSQL/fbt-repository@a290acc
The text was updated successfully, but these errors were encountered: