Greetings, In a single catalog LLBL project, I create an adapter using this code

 DataAccessadapter.ConnectionStringKeyName = "JCLApp.ConnectionString"
dim myAdapter as IDataAccessAdapter = New DataAccessAdapter

My connection string is using the catalog name WORM123 while the catalog name in the persistence info is WORM.

LLBL's refernce manual explains that when CatalogNameUsage property is set to **DEFAULT **

nothing is done to the catalog name specified in the persistence info.

(I didn't do any CatalogNameOvewrites or CatalogNameUsageSetting in my AppConfig file).

Whats happening is that the adapter is still using the catalog name from the connection string and not the one in the persistence info !! Am I missing something here ??

As you don't set ANY catalog name overwrite information, it will never overwrite the name, as it doesn't have any name to overwrite it with.

When you switch on tracing, what's the catalog name used in the queries, WORM or WORM123?

Could you please check also which catalog is generated into the persistence info in the PersistenceInfoFactory.vb in your database specific project? (in the bucket creation routines)

Otis wrote:

As you don't set ANY catalog name overwrite information, it will never overwrite the name, as it doesn't have any name to overwrite it with.

This is how I understand LLBL's CatalogName/SchemaName handling 1- LLBL will always store the catalog name in the presistence info 2- LLBL's queries will always use a catalog name to locate tables, ... 3- The adapter's property CatalogNameUsage controls how LLBL handles the catalog name. * If CatalogNameUsage is left to its Default value then LLBL's DQE queries will use the catalog name from the presistence info. * If CatalogNameUsage is set to Clear value then LLBL's DQE Clears the catalog name specified in the persistence information and use the catalog name specified in the connection string. * If CatalogNameUsage is set to ForceName value then LLBL's DQE forces the name specified in the property DataAccessAdapter.CatalogNameToUse

Otis wrote:

When you switch on tracing, what's the catalog name used in the queries, WORM or WORM123?

Strangly the resulting query does NOT have any catalog name specified in it which negates point 2 in my understanding

Otis wrote:

Could you please check also which catalog is generated into the persistence info in the PersistenceInfoFactory.vb in your database specific project? (in the bucket creation routines)

the catalog **WORM **is the one generated into the persistence info

omar wrote:

Otis wrote:

As you don't set ANY catalog name overwrite information, it will never overwrite the name, as it doesn't have any name to overwrite it with.

This is how I understand LLBL's CatalogName/SchemaName handling 1- LLBL will always store the catalog name in the presistence info 2- LLBL's queries will always use a catalog name to locate tables, ... 3- The adapter's property CatalogNameUsage controls how LLBL handles the catalog name. * If CatalogNameUsage is left to its Default value then LLBL's DQE queries will use the catalog name from the presistence info. * If CatalogNameUsage is set to Clear value then LLBL's DQE Clears the catalog name specified in the persistence information and use the catalog name specified in the connection string. * If CatalogNameUsage is set to ForceName value then LLBL's DQE forces the name specified in the property DataAccessAdapter.CatalogNameToUse

Correct. So if you don't set ANYTHING, the catalog name isn't touched at all.

Otis wrote:

When you switch on tracing, what's the catalog name used in the queries, WORM or WORM123?

Strangly the resulting query does NOT have any catalog name specified in it which negates point 2 in my understanding

Hmm.

Otis wrote:

Could you please check also which catalog is generated into the persistence info in the PersistenceInfoFactory.vb in your database specific project? (in the bucket creation routines)

the catalog **WORM **is the one generated into the persistence info

As you've said that you haven't defined any name overwriting in the config file and you don't set the catalog name overwriting property in the DataAccessAdapter instance, could you please set a breakpoint in DataAccessAdapter.HandleCatalogName(), the Select Case statement? It should simply step into the Default section and return.

OK.. this what I came up with so far. * The AppConfig's connection string is refering to a database WORM123 which is NOT a real database. * The presistence info uses the catalog name WORM which is the actual database * The resulting SQL queries use the catalog name WORM * I get a run-time error that login failed for the database WORM123

The reasoning I came up with is although the DQE ignores the catalog name from AppConfig's connection string, it still uses the catalog name in the AppConfig's connection string to login to SQL server.

Questions: If I speify a connection string when creating the adapter object, does the DQE use the AppConfig's connection string or that of the adapter to login to SQL?

omar wrote:

OK.. this what I came up with so far. * The AppConfig's connection string is refering to a database WORM123 which is NOT a real database. * The presistence info uses the catalog name WORM which is the actual database * The resulting SQL queries use the catalog name WORM * I get a run-time error that login failed for the database WORM123

The reasoning I came up with is although the DQE ignores the catalog name from AppConfig's connection string, it still uses the catalog name in the AppConfig's connection string to login to SQL server.

Questions: If I speify a connection string when creating the adapter object, does the DQE use the AppConfig's connection string or that of the adapter to login to SQL?

If you specify a connection string to the dataaccessadapter constructor, it will use that one.

The connection string is used to connect to the database SERVER, and to get access to 'a' catalog, the catalog in the connection string. The queries use full name specifications, so you can have access to multiple catalogs if you want, using the same connection.

How can I do <sqlServerCatalogNameOverwrites> in code instead of AppConfig

omar wrote:

How can I do <sqlServerCatalogNameOverwrites> in code instead of AppConfig

Not at the moment, that will be available in 1.0.2005.1, you then can pass a hashtable with overwrites to the DataAccessAdapter constructor.

Otis wrote:

omar wrote:

How can I do <sqlServerCatalogNameOverwrites> in code instead of AppConfig

Not at the moment, that will be available in 1.0.2005.1, you then can pass a hashtable with overwrites to the DataAccessAdapter constructor.

is that the upcoming release ??

omar wrote:

Otis wrote:

omar wrote:

How can I do <sqlServerCatalogNameOverwrites> in code instead of AppConfig

Not at the moment, that will be available in 1.0.2005.1, you then can pass a hashtable with overwrites to the DataAccessAdapter constructor.

is that the upcoming release ??

Yes, the last upgrade for the current codebase. After that, v2.0 development will start in full and the next release then thus will be v2.0