LLBLGen 2.0 MS SQL Server Adapter

I've run into a situation where we have a table with a varchar field as the primary key. This table has a relation to another table using this field but the casing of the value in the field of the related table does not always match the casing of the value in the field of the PK table. For instance, the value of the field in the PK table may be 'ABC123' but in the FK table the related field will contain 'abc123'.

SQL Server handles this fine but I've confirmed that the inconsistent casing prevents the prefetch path logic from matching the related rows up to the PK entity.

Is this something that LLBL can account for internally? Right now I can update the field in the FK table so that it always matches the casing of the field in the PK table but it would be better if the prefetch path processing logic didn't depend on identical casing since SQL Server doesn't.

Thanks!

I think this feature was introduced in v2.6 (http://llblgen.com/TinyForum/Messages.aspx?ThreadID=13003&StartAtMessage=0&#74805). From the manual:

.NET 2.0+: Setting to let the framework produce case-insensitive based hashcodes for string values in entity fields. Through a new static property on the new class EntityFieldCore: EntityFieldCore.CaseSensitiveStringHashCodes, a developer can control if the GetHashCode() method for a string typed entity field will produce a hashcode based on the case sensitive version of the string value or the case insensitive version. Default is true: case sensitive hashcodes. Set this setting to false if you work with a database which has casing differences between FK and PK values. You can also set this setting in the config file by adding a new key / value pair to the appSettings element: caseSensitiveStringHashCodes, which has as values either 'true' or 'false'.

So you could go to v2.6 and use the setting or just reformat your data so the hashing on the relations works as expected.