We are using 3 catalogs, indeed 3 different databases which reside on the same server. In the Project Explorer we've added the requred entities from the several databases. After generating the DAL, the PersistanceInfoProvider shows which entities belong to which database.

The documentation states that, when accessing an entity the corresponding database would be used. However, the database remains always on the connection string as set in the web.config. Removing this key results in an error that the connection string has not been found.

I'm using a LLBLGen 3 self-servicing project on a MySQL database with the dotConnect driver from devArt.

The workaround we made is to set the ActualConnectionString to the corresponding database with each webmethod request. But this results in mutual errors when many users are using the database (the connections of other users are used).

If found the semaphore solution provided in this forum, but that does not work with LLBLGen 3, and I think it is very slow.

I also found we should use the Adapter approach, but this requires several days of rewriting the code.

Why is the PersistanceInfoProvider not working? I remember with LLBLgen 2.5 and MS SQL Server this worked without problems, you even had to override the connectionstrings in de configuration file to use a production database.

I really want this behaviour to work as this is the solution to the non-threadsafe errors.

Do you have an CatalogNameOverwrites or SchemaNameOverwrites in the application Configuration file?

You ran in an undocumented feature: we didn't document this properly, and for that my apologies.

In v2 and earlier, multiple catalog support wasn't implemented. This was added in v3, but as emitting the catalog name by default could cause problems for some people, we added a switch for this, which is off by default.

To enable it, please add the following to your application's web.config file (appSettings section).

<add key="mySqlIncludeCatalogNameInObjectNames" value="true" />

This will cause the catalog names to be added to the queries.

We'll add proper documentation for this in v3.5's docs.

Thank you so much Otis, this was exacty where I was looking for!

Is there toevallig another hidden feature to manually add the databasename with each query? So it's not taken from the PersistenceInfoProvider but by parameter or something?

Just enable the feature to get the catalog name in the query, then use catalogname overwriting to overwrite that name with another one, as described in the documentation. (i.e. define the overwriting in the config file of your application if you're using selfservicing)

I can't find in the documentation how to do that for MySQL.

Now that I know the databasename is added to the query, I suppose there could be runtime code to override the catalogname as provided in PersistenceInfoProvider?

Can it be done with DynamicQueryEngine dqe = new DynamicQueryEngine(); dqe.PerCallCatalogNameOverwrites.... ?

Config based name overwriting: See this article in the docs

per call overwriting: See this article in the docs

I found that already too, but it was not clear to me it applies to SelfServicing too. I'll look into it, thank you Otis!

Mastermind wrote:

I found that already too, but it was not clear to me it applies to SelfServicing too. I'll look into it, thank you Otis!

The config file based one does apply to selfservicing. You can set that in code as well, through the CommonDaoBase, but that's global, similar to the config file approach. Adapter has per-call catalog name overwriting.

That is not the solution, since that is global and not thread-safe. I rewrote the whole datalogic unit from SelfServicing to DataAdapter. Hell of a job, but this works perfectly.

Mastermind wrote:

That is not the solution, since that is global and not thread-safe. I rewrote the whole datalogic unit from SelfServicing to DataAdapter. Hell of a job, but this works perfectly.

Adapter is indeed designed for that, as stated in the Template groups section under 'Concepts'. I'm sorry it took a lot of work to move from selfservicing to adapter. It's not really possible to make it a 'per call' feature for selfservicing, as you never call the persistence logic directly, it's done for you.