Consider a primary feature source with the following sample data.
| ID
|
| A001
|
| A002
|
| A003
|
| A004
|
| A005
|
| A006
|
| ....
|
| A194
|
Now consider that we are joining to a secondary feature source via ODBC, with the following sample data.
| ID | Value
|
| A001 | A
|
| A002 | C
|
| A003 | A
|
| .... | ..
|
| A015 | B
|
| a016 | C
|
| A017 | A
|
| A018 | C
|
| .... | ..
|
| A044 | A
|
Suppose now we create a layer off of this joined feature source and theming on the values of the "Value" property, including a default style.
If you preview this layer, you'll notice a "break" at A016 (as it doesn't have a corresponding match) which is fine, but a fair amount of features "after" A016 (number unknown) will also be NULL on the ODBC side, until rendering resumes normally, see attached image for a visual explaination.
If you were to view this data via the schema report, the joined class would look something like...
| ID | Joined_ID | Joined_Value
|
| A001 | A001 | A
|
| A002 | A002 | C
|
| A003 | A003 | A
|
....
| A015 | A015 | B
|
| A016 | NULL | NULL <--- Correct, there is no corresponding match
|
| A017 | NULL | NULL <--- This is not correct, there is a corresponding match.
|
| A018 | NULL | NULL <--- Ditto
|
.... Some features later....
If the a016 was changed to A016 on the ODBC side, the feature join will render normally.
