Ref to ThreadID 13732

I've got LLBLGen Pro v2.6 (June 6th, 2008 ) and the issue still exists. The database name is hardcoded in the stored procedure call. Here's the code snippet:

        public static DataTable EmployerAccountsDelProc(System.Int32 userId, System.Int32 updatedById, System.Byte userTypeId, DataAccessAdapter adapter)
        {
            SqlParameter[] parameters = new SqlParameter[3];
            parameters[0] = new SqlParameter("@user_id", SqlDbType.Int, 0, ParameterDirection.Input, true, 10, 0, "",  DataRowVersion.Current, userId);
            parameters[1] = new SqlParameter("@updated_by_id", SqlDbType.Int, 0, ParameterDirection.Input, true, 10, 0, "",  DataRowVersion.Current, updatedById);
            parameters[2] = new SqlParameter("@user_type_id", SqlDbType.TinyInt, 0, ParameterDirection.Input, true, 3, 0, "",  DataRowVersion.Current, userTypeId);

            DataTable toReturn = new DataTable("EmployerAccountsDelProc");
            bool hasSucceeded = adapter.CallRetrievalStoredProcedure("[DevDB].[dbo].[employer_accountsDelProc]", parameters, toReturn);

            return toReturn;
        }

As mentioned in the previous thread, the hard-coding of the database name causes the call to the stored procedure to access the original database and not the database name specified with: <sqlServerCatalogNameOverwrites> <add key="DevDB" value="ProdDB" /> </sqlServerCatalogNameOverwrites>

PS: The color isn't supported within the code markup in the forum - if I enclose it within the code tags, the color tags appear as literals

Do other queries (fetching entities) use the new ProdDB catalog?

(Edit) Are the DevDB & the ProdDB on the same server? If not, then did you change the connection string?

Walaa wrote:

Do other queries (fetching entities) use the new ProdDB catalog?

(Edit) Are the DevDB & the ProdDB on the same server? If not, then did you change the connection string?

Hi!

Other queries work fine... it is only the stored procedure calls that are an issue. After removing the database name prefix from the calls, it works fine.

Both the DevDB and ProdDB databases are on the same server.

-Nitin

We can't reproduce it as our tests shows the name gets corrected. Would you please put a breakpoint in the generated class DataAccessAdapter, method: CallRetrievalStoredProcedure (the dataTable overload) and check whether the name of the proc is correctly corrected?

Just to make sure other queries access the ProdDB, would you please take the DevDB offline, and make sure the connection string is pointing to the ProdDB.

Then run your tests again, I think either everything works as expected, or everything should fail, in this case there might be something wrong in the config section.

Would you please post the code calling the proc and the .config file? remove any cretical info.. (username/pswd)