Hello.

I found this thread stating that change of catalog name should not cause issues for SelfServicing: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=3299&HighLight=1.

I have a db with many tables. When moving to production I will fetch from one of those tables in a separate db.

Here is my code for that:

public static RimCollection GetRIMs(string approverConnectionStringDB) {
            string actualConnectionString = DbUtils.ActualConnectionString;
            DbUtils.ActualConnectionString = approverConnectionStringDB;
            RimCollection rims = new RimCollection();
            rims.GetMulti(null);
            DbUtils.ActualConnectionString = actualConnectionString;
            return rims;
        }

This fails due to catalog name problems. I can see from the sql in the exception that the generated code catalog name is used:

"\r\n\tQuery: SELECT [AD_Manager].[dbo].[RIM].[Id], [AD_Manager].[dbo].[RIM].[DisplayName], [AD_Manager].[dbo].[RIM].[Email], [AD_Manager].[dbo].[RIM].[BA_CODE] AS [BaCode] FROM [AD_Manager].[dbo].[RIM] \r\n"

I debug (all the way in to where llblgen creates the sqlconnection) and check that my other db is Initial Catalog in the query string used: data source=bytetec-vpc01;initial catalog=AD_Manager_2;integrated security=SSPI;persist security info=False;packet size=4096

Ideas?

Thanks, Tore.

I am using: v2.5 Final on Sql Server 2005.

You should use Catalog name overwriting

Thanks Daelmo.

I saw that section. It allows me to overwrite using configuration. I am however inside a web part in SharePoint so I would like to avoid that. I also saw that for Adapter it is possible to overwrite catalog name at runtime per DataAccessAdapter. I did however not find a way to do this for SelfServicing.

The thread that I referred to in my first post is obsolete it seems and I have to fix my issue using configuration. I realize that I have to enter a mapping from AD_Manager to empty string. That will make LLBLGen use the Initial Catalog from the connection string. So'll just have to put that into my install.

You should perhaps implement an option to add/remove catalog name overwrite mappings in the DbUtils class. That would have made this a whole lot easier.

--tore

If you use an empty catalog name in the catalog name overwrite section in the config file. Then the catalog name used in the connection string is the one which will be used.

And you can set the connection string at runtime using DbUtils.ActualConnectionString

Manual wrote:

The DbUtils class lets you set the global connection string to use for every connection to the database. This setting overrides the connection string read from the appSettings section in the .config file. Once the setting is set, every connection to the database uses the set connection string. You set the connection string to use at runtime using the following code:

ref: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=13082

Otherwise you might want to read this: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=15107

I still think you guys should make this a runtime option also for SelfServicing: implement an option to add/remove catalog name overwrite mappings in the DbUtils class.

Thanks, Tore.

Or even better, boolean property at DbUtils: UseCatalogNameFromConnectionString. Raising that flag would force use of the Initial Catalog in the connection string.

The problem is that DbUtils has no access to the DQE instance used at runtime, and the name overwriting is done inside the DQE. SqlServer connects first to the service you named in the connection string and then it connects to the initial catalog. In sqlserver you can access any catalog the user has access to from there, as you're connected to the service AND to the initial catalog (but that's not the only catalog you're allowed to connect to).

When there's a catalog name present in the query, that catalog is used otherwise sqlserver uses the catalog you're already connected to, the initial catalog.

If you want to do this through code, instead of through configuration (which indeed is a problem with sharepoint), you should set the catalognameoverwrites in the DynamicQueryEngine inside a DAO instance as there the DQE instance is known. Unfortunately, the constructor of the DAO classes instantiate the DQE:

public CustomerDAO() : base(InheritanceInfoProviderSingleton.GetInstance(), new DynamicQueryEngine(), InheritanceHierarchyType.None, "CustomerEntity", new CustomerEntityFactory())
...

What should happen here is that instead of new DynamicQueryEngine(), a method should be called which allows extension to this so you can add the overwrites there, perhaps indeed by a call to DbUtils which uses only static data.

However with a change in the template 'dao.template' (by creating a copy, and by creating a new templatebindings file to bind the copy to the templateID SD_EntityDAOTemplate, see SDK for details on this) so it calls your custom method which allows injection of a hashtable of type CatalogNameOverwriteHashTable (it's a type in the ORMSupportClasses, used in Adapter), and which sets the DQE property PerCallCatalogNameOverwrites it will allow overwrites on SelfServicing as well.

It's however more cumbersome than simply setting things.

We'll try to fix this in v3 with a change to the selfservicing code base so this will be easier.

Thanks for this Otis.

I will get the customer to change the SharePoint web application config. I am looking forward to an improvement in v3. I hope you find the time to prioritize this

Best regards, Tore.

Hello.

Im beginner user of LLBLGEn. I cannot change database during runtime. Im using self-servicing and when i do change of CommonDaoBase.ActualConnectionString with new initial catalog database will not change. When im trying save my Entity always it write to original database (catalog). I need this feature because i have a lot archives of dbs and each year appears new db with the same structure.

I read your dialog and i thought that LLBLGen maybe found better solution since you solved this thopic. I use LLBLGen version 4.2 and SQL server is 2012.

And sorry for my worse english.

Best regards Martin

when i do change of CommonDaoBase.ActualConnectionString with new initial catalog database will not change

Are you just changing the catalog name, or are you changing the server?

To change the catalog name: You may use the CommonDaoBase.ActualConnectionString indeed but only if you set the CatalogNameOverwrite to an empty string in the database.

<sqlServerCatalogNameOverwrites>
    <add key="OOriginalCatalogName" value="" />
</sqlServerCatalogNameOverwrites>

Thanks for your answer.

But result is the same. Now i have in app.config (in application, no in generatedCode) following added code:

  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup">
    </sectionGroup>
    <section name="sqlServerCatalogNameOverwrites" type="System.Configuration.NameValueSectionHandler"/>
  </configSections>
  <sqlServerCatalogNameOverwrites>
    <add key="ConnectionString.SQL Server (SqlClient)" value="" />
  </sqlServerCatalogNameOverwrites>

And change connections string i do follow way :

CommonDaoBase.ActualConnectionString = "data source=BC4APVYVOJ;initial catalog=ICS2;integrated security=SSPI;persist security info=False;packet size=4096"; 

I add new record to table after this section but result appears in database ICS no in ICS2.

Thank you very much for you effort

<sqlServerCatalogNameOverwrites> <add key="ConnectionString.SQL Server (SqlClient)" value="" /> </sqlServerCatalogNameOverwrites>

It seems that you are not using the correct original catalogName (the one used in dev time). You are using the connectionString key name instead.

So if the current catalogname from the connection string is ICS2, it must have been something like ICS1, ICS, ICSDev ...I'm trying to guess to give you a hint of what to look for.

Ohh thank you very much.

It's working. I'm absolutely blind.