I'm using LLBLGen Pro 2.0.0.0 Final with adapter and .NET 2.0/c# connecting to a SQL Server 2005 dB.

I'm not sure this is a LLBL issue but as I'm scratching my head I thought I'd run it past the community in case anyone else has had a similar problem.

I have added sqlServerCatalogNameOverwrites section to my appplication's config file and when the user sets the connection properties a stored procedure is executed that is defined as "IHSecurity.dbo.spGetProduct" but with the following overwrite this is to transformed into ".dbo.spGetProduct"

 <sqlServerCatalogNameOverwrites>
    <add key="IHCRM" value="" />
    <add key="IHSecurity" value="" />
  </sqlServerCatalogNameOverwrites>
  <appSettings>

Now this is working a treat on Vista and XP but having just installed the application on Windows Server 2003 SP2, the overwrite is not being picked up so the procedure executes as "IHSecurity.dbo.spGetProduct"

I've created a test app to confirm that I can read the overwrite values out of the config in the same manner as SD.LLBLGen.Pro.DQE.SqlServer's DynamicQueryEngine cTor, get no output using DQE logging and tried altering the install folder permissions.

Now a bit of payback for anyone taking the time to read my thread. If you're wondering how I know what code is in the DynamicQueryEngine's cTor check out Lutz Roeder's must have .NET Reflector at http://www.softpedia.com/get/Programming/Other-Programming-Files/Lutz-Roeder-s-NET-Reflector.shtml

Specifying an empty string as new name, will make the SQL target the catalog specified in the connection string.

Check the catalog name specified in the connection string.

Hi Walaa.

You are correct that when the new name is empty the procedure is executed against the database that the app is connected to because no database name is specified eg. "exec .dbo.spGetProduct". My problem is that the database name is not replaced with the overwrite name so no matter which database my app is connected to the procedure always executes against the IHSecurity database eg. "exec IHSecurity.dbo.spGetProduct"

This sounds like an old bug that was solved a long time ago. Which runtime library version of LLBLGen Pro are you using? To get the RTL version, consult the following thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7722

My runtime library version is 2.0.7.11

Please try the latest version released on (16-dec-2007). Download and run the full installer.

Unfortunately that didn't help - it seems to be a more general issue reading from the config file although the application is able to save to the config file successfully

My application is called inspHire.CRM.exe so I have an inspHire.CRM.exe.config file and bizarrely enough if I copy the file and create a inspHire.CRM.config file then the overwrite works and my connection properties get saved into inspHire.CRM.exe.config

Next issue comes when running the application for a second time as it simply quits (without error) when attempting to pull the connection properties out of the config file.

Hi Chris, I'll try run a repro-test on a virtual machine and let you know what I have ASAP. Googling for the issue I saw your post at MSDN, I hope it would bring some lights on this.

Thanks for the offer daelmo and hope you haven't got too far with your repro-test.

I've managed to re-create the issue on my Windows Server 2003 SP2 virtual machine and also found this http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1892959&SiteID=1 post which explains the cause of the problem. My intuition that this wasn't an LLBL Gen issue was correct and in fact the boys from Bill's place get all the plaudits!

Basically, if you add a manifest file to your application executable (which you need to do to be fully compliant with Windows Vista) then the ConfigurationManager on Windows Server 2003 will look for a config file in the following format "applicationname.config" rather than "applicationname.exe.config". From the posts I've found this only appears to affect Windows Server 2003 and Windows Home Server.

I've removed the manifest file from my executable and everything is working fine and dandy.