Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
3.1.15
-
None
Description
In the file https://github.com/mariadb-corporation/mariadb-connector-odbc/blob/master/ma_string.c there a two lines who contradict each other:
On https://github.com/mariadb-corporation/mariadb-connector-odbc/blob/852f63465b03045dba73cc36fc5710aea0f55b5c/ma_string.c#L213 the int variable Flag is created with an initial value of 0 and in https://github.com/mariadb-corporation/mariadb-connector-odbc/blob/852f63465b03045dba73cc36fc5710aea0f55b5c/ma_string.c#L257 the condition is true if the Flag value is 0, which is always the case, since the Flag value never changes after initialization.
As far as i can tell the value of flag should depend on the values of PrimaryCount and/or UniqueCount, to avoid to compare all columns and not just the primary key/unique columns.
A quick fix is to set the value of Flag prior to the for loop (line 262):
...
|
if(PrimaryCount) |
{
|
Flag = PRI_KEY_FLAG;
|
}
|
else if(UniqueCount) |
{
|
Flag = UNIQUE_KEY_FLAG;
|
}
|
for (i= 0; i < MADB_STMT_COLUMN_COUNT(Stmt); i++) |
{
|
...
|
I have attached a "corrected" version of ma_string.c for comparison.
Attachments
Activity
Exactly as I remembered - some tests are failing. So, it's not just this.
Fixed support of unique indexes for positioned operations
The report is talking only about code creating WHERE clause, but that was not enough to make it work. Some optimizations ere done along the way to reduce number of calls to collect required metadata. Index information is also preserved for that purpose(reducing number of queries to collect metadata).
Thank you for your report. I suspect that was at some deliberately left like this. But it's apparently the time to fix it