I am using : SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll vers. 2.6.8.1013 SD.LLBLGen.Pro.DQE.SqlServer.NET20.dll vers. 2.6.8.1006

Adapter

Hi, I have an application that read data in a SQL Server 2005 Db and write data in a different SQL Compact DB. The SQL Server 2005 and the SQL Compact database have different schema, so I have 2 different LLBL data models and I use two different DataAccessAdapter (completely different classes), one for the SQL Server 2005 DB and one for the SQL Compact DB. To use SQL Compact DB I have set DQE Compatibility mode to SqlServerCE35 (4) by calling the method SetSqlServerCompatibilityLevel of the Sql Compact DataAccessAdapter. The problem is that this setting, as I have experimented, affect also the DataAccessAdapter used to fetch entities in SQL Server 2005 DB, in fact when using the DataAccessAdapter for the SQL 2005 DB I have this exception :

"Unknown connection option in connection string: initial catalog."

The Stack Trace is : in System.Data.SqlServerCe.ConStringUtil.ParseStringIntoHashtable(String conString, Hashtable values) in System.Data.SqlServerCe.ConStringUtil.ParseConnectionString(String& connectionString) in System.Data.SqlServerCe.SqlCeConnection.set_ConnectionString(String value) in BSS.Vortex.LLBL.Main.DatabaseSpecific.DataAccessAdapter.CreateNewPhysicalConnection(String connectionString) in SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.GetActiveConnection() in SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.CreateSelectDQ(IEntityFields2 fieldsToFetch, IFieldPersistenceInfo[] persistenceInfoObjects, IPredicateExpression filter, Int64 maxNumberOfItemsToReturn, ISortExpression sortClauses, IRelationCollection relationsToWalk, Boolean allowDuplicates, IGroupByCollection groupByClause, Int32 pageNumber, Int32 pageSize) in SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntityUsingFilter(IEntityFields2 fieldsToFetch, IFieldPersistenceInfo[] persistenceInfos, IRelationPredicateBucket filter) in SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntityUsingFilter(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse, IRelationPredicateBucket filter, ExcludeIncludeFieldsList excludedIncludedFields) in SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch, IPrefetchPath2 prefetchPath, Context contextToUse, ExcludeIncludeFieldsList excludedIncludedFields) in SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.FetchEntity(IEntity2 entityToFetch) ... ... Stack Trace in my Procedures

Is it possible to mix SQL compatibility mode so I can use two different DataAccessAdapter, one for a SQL 2005 DB and one for a SQL Compact DB? Thanks in advance, Daniele.

You'll have to set it in code. Use the DataAccessAdapter.SetSqlServerCompatibilityLevel() static method.

Walaa wrote:

You'll have to set it in code. Use the DataAccessAdapter.SetSqlServerCompatibilityLevel() static method.

I have used it, calling the static method SetSqlServerCompatibilityLevel in the SQL Compact DataAccessAdapter, but I have the error when I use the SQL Server 2005 DataAccessAdapter. May I have to call SetSqlServerCompatibilityLevel every time I use one kind of DataAccessAdapter?

I have solved. Just before using SQL Compact DataAccessAdapter I call SetSqlServerCompatibility passing SqlServerCE35 parameter. Then I switch the compatibility level back to SqlServer2005 and perform operations with SQL 2005 DB, then I switch compatibility level to SqlServerCE35 and perform the operations with SQL Compact DB, then I switch to SqlServer2005 and so on... Is there a better way to have the same behavior?

It's currently a static value in the SqlDQE, including the providerfactory so it's not per instance. To make this a per-instance feature we've to alter the design of the DQE (which is planned for v3). For now your only option is to set the compatibility level per action.

Another work around that Frans and I think might work for you is: To load 2 instances of the SqlDQE in 2 different AppDomains and use one for each database, after all, entities are serializable with change tracking, so you can just serialize the entities to the other appdomain and persist them there, or whatever you want to do with them.

Before trying this solution could you tell me when the version 3 will be available? Thank You, Daniele.

Somewhere in 2009, though not before june

Ok, Thank You. I will use two different appdomains.