Main.ConnectionString not being used in SelfServicing mode v2.0

Posts   
 
    
Posts: 15
Joined: 01-Mar-2005
# Posted on: 14-Aug-2006 18:55:42   

Hi I have a question regarding the Self-Servicing option in V2.0.

I have generated my code with the following options:

General Settings: Target Lang: C# Target Platform: .NET 1.1 Template Group: Self-Servicing

Template Bindings: SD.TemplateBindings.SharedTemplates.BackwardCompatibility.NET11x

Tasks to Execute: SD.Presets.SelfServicing.TwoClasses2003

When I generate the code using these options it also generates the HelperClasses file PersistenceInfoProvider.cs (which according to the documentation is an Adapter Specific File). Although the project builds fine with this PersistenceInfoProvider class included, it seems to be using the catalog name in the class's AddElementMapping method instead of picking the catalog name up from the web.config file - therefore when i change the initial catalog in the Main.ConnectionString within the web.config it ignores this change.

The effect of the problem is this:

My development database is called: dovetail_rrr_tss. My live database is called: LiveDB

On the live machine I use the following web.config (excerpt):

<appSettings> <add key="Main.ConnectionString" value="data source=MySqlServer;initial catalog=LiveDB;User ID=MyUser;Password=MyPass;persist security info=False;packet size=4096"/>

And on the live server I get this error: (which mentions the development SQL server catalog):

Server Error in '/' Application.

An exception was caught during the execution of a retrieval query: Invalid object name 'dovetail_rrr_tss.dbo.Staff'.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException: An exception was caught during the execution of a retrieval query: Invalid object name 'dovetail_rrr_tss.dbo.Staff'.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[ORMQueryExecutionException: An exception was caught during the execution of a retrieval query: Invalid object name 'dovetail_rrr_tss.dbo.Staff'.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception.] SD.LLBLGen.Pro.ORMSupportClasses.RetrievalQuery.Execute(CommandBehavior behavior) +232 SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.ExecuteMultiRowRetrievalQuery(IRetrievalQuery queryToExecute, ITransaction containingTransaction, IEntityCollection collectionToFill, Boolean allowDuplicates, IEntityFields fieldsUsedForQuery) +414 SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.PerformGetMultiAction(ITransaction containingTransaction, IEntityCollection collectionToFill, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IPredicate selectFilter, IRelationCollection relations, Int32 pageNumber, Int32 pageSize) +247 SD.LLBLGen.Pro.ORMSupportClasses.DaoBase.GetMulti(ITransaction containingTransaction, IEntityCollection collectionToFill, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IEntityFactory entityFactoryToUse, IPredicate selectFilter, IRelationCollection relations, Int32 pageNumber, Int32 pageSize) +48 SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase.GetMulti(IPredicate selectFilter, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IRelationCollection relations, Int32 pageNumber, Int32 pageSize) +161 SD.LLBLGen.Pro.ORMSupportClasses.EntityCollectionBase.GetMulti(IPredicate selectFilter) +25 TaxSaverTickets.StaffLogin.btnLogin_Click(Object sender, EventArgs e) in c:\inetpub\wwwroot\app\StaffLogin.aspx.cs:64 System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108 System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33 System.Web.UI.Page.ProcessRequestMain() +1292

JimHugh
User
Posts: 191
Joined: 16-Nov-2005
# Posted on: 14-Aug-2006 20:03:08   

Check out the DBUtils functionality in the docs.

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 15-Aug-2006 06:58:49   

Please check the docs for "Using the generated code -> Application configuration through .config files".

Where you can find how to change the catalog name and/or the schema name.

Posts: 15
Joined: 01-Mar-2005
# Posted on: 15-Aug-2006 12:01:14   

OK, we just tried this:

We have a SQL Server catalog called DB1 which we have made offline.

The LLBLGen code has all been generated using this catalog (DB1).

We change the web.config to point to DB2, which is online.

Now we get this error when we run the webapp:

An exception was caught during the execution of a retrieval query: Database 'DB1' cannot be opened because it is offline.. 

ORMQueryExecutionException: An exception was caught during the execution of a retrieval query: Database 'DB1' cannot be opened because it is offline.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception.]
   SD.LLBLGen.Pro.ORMSupportClasses.RetrievalQuery.Execute(CommandBehavior behavior)

We are using Self Servicing, .NET 1.1. We have just upgraded to LLBLGEN PRO v2.0 -- we have been using the approach of changing the web.config for live deployment for years with no problems, but the same strategy is not working for 2.0.

The documentation in the section "Generated code - Application configuration through .config files" says the following:

As LLBLGen Pro generates the catalog name into the code (except in the situation of SelfServicing with just 1 catalog)

We _are _ using Self-Servicing with 1 catalog.

We think that the persistenceinfoprovider class is the problem as this is the only place in the generated code where we can see the string DB1.

Jessynoo avatar
Jessynoo
Support Team
Posts: 296
Joined: 19-Aug-2004
# Posted on: 15-Aug-2006 16:15:32   

Changing the connection string is indeed not enough to switch the catalog name used in the query statements since as you've seen, the persistenceinfoprovider includes some hardcoded elements.

But then, as described in the section mentioned above a system has been introduced, which allows specifying names overwrite in the web.config.

When the SQLServer Dynamic Query engine is instanciated (that class is shared by adapter and selfservicing scenario, it's a base component), it's looking for the <sqlServerCatalogNameOverwrites> section from your config file, and then performs the modification on the fly on subsequent queries.

So if you follow the config specified, it should result in your queries being updated to DB2.