Just started an upgrade from LLBLGen 5.4 to 5.9. We have MANY generated outputs of LLBLGen all of which are coordinated from a management library that does the standard initialization processes like creating the Data Access Adapter.

Since this is a SaaS product and sold to onsite customers the catalog name(s) of the various libraries are "wrong" when in use because there are infinite variations of database names depending on the specific customer install. Not a problem since CatalogNameOverwriteHashtable allows me to easily set a CatalogNameUsage of Clear and magically the database name is no longer part of the queries and we manage everything to connect to the correct database via the connection string.

This process has worked perfectly since 2.x and has quite successfully survived upgrades all the way to 5.4. In the upgrade process to 5.9 we have discovered that the Queries are now generating with Catalog names even though we are still passing Clear.

A workaround of using

new CatalogNameOverwriteHashtable(CatalogNameUsage.ForceName) { { "*", "" } } ;

appears to work, but the previous method of

new CatalogNameOverwriteHashtable(CatalogNameUsage.Clear);

is not working.

I'm not seeing any indication that Clear is unsupported and I'm obviously concerned that changing this may cause unexpected results that require a LOT of extra testing to discover if a problem exists. Suggestions?

We'll look into it!

As you didn't provide any more information, I assume this is for sql server and the queries that don't work anymore are regular entity queries and not stored procedure calls. Also, we assume you don't use configfile/runtimeconfiguration for catalog name overwrites.

reproduced. (Entity query)

You can keep using your workaround btw, it should lead to the desired results as that's the designed behavior.

It goes wrong because the hashtable is empty, there are checks in place which make an early exit if the hastable is empty (this was introduced by an optimization, in 2018 ). Our tests succeeded because the hashtable wasn't empty, hence it worked here. So your workaround should be sufficient or adding an entry with the clear should be sufficient to keep your code working. We'll look into adding an extra check to v5.8.x and 5.9.x for the situation where the hashtable is empty but clear is specified.

Fixed in hotfix builds 5.8.5 and 5.9.1 which are now available

Otis wrote:

Fixed in hotfix builds 5.8.5 and 5.9.1 which are now available

Nice!. Fast, responsive, smart!

I thought I was going nuts for hours as I was trying to understand what I was doing wrong. Thanks for confirming that my final solution and pain was correct and worth the effort.