Hi,

My database has a dot in the database name so part of my connection string looks like "Initial Caltalog = XX.YYYY". It seems that LLBLGen is using YYYY.dbo.TableName in generated SQL instead of XX.YYYY.dbo.TableName.

As far as I know a dot in a database name is allowed by SQLServer 2005. I am using latest 2.0 version of LLBLGen.

Can I expect this to be fixed in 2.5 or are there other things that rely on this behavior that would get broken by such change.

Best regards, Robert Wilczynski.

Robert.W wrote:

Hi,

My database has a dot in the database name so part of my connection string looks like "Initial Caltalog = XX.YYYY". It seems that LLBLGen is using YYYY.dbo.TableName in generated SQL instead of XX.YYYY.dbo.TableName.

As far as I know a dot in a database name is allowed by SQLServer 2005. I am using latest 2.0 version of LLBLGen.

Can I expect this to be fixed in 2.5 or are there other things that rely on this behavior that would get broken by such change.

There's a problem: name overwriting. The '.' is used for delimiting names. Now, IF [] are used to specify the fragments, it could be done, however people are also able to for example specify a proc name with catalog.schema.name with no [] and it also has to work. If dots are used in names, it's not able to make the distinction.

Do you really need to use the . in the catalog name?

Frans,

Thanks for clarifying this. I guess I will just change the convention and use a hyphen (-) instead of dot. I can think of a couple of ways you could actually make the "dotted DB names" work (by checking with SQL Server if such database is registered and based on that knowledge making appropriate decisions when generating SQL) but that's probably not worth the team's effort.

Best regards, Robert Wilczynski.

Thanks Robert. If you really need a fix for this (for example, if your client deliberately asks for a . in the catalog name) we could try to add support for this.

Frans,

The dot separated database names **was **( ) our internal convention for doing things like hosting a staging and test database on the same DB server (like MyApp.Staging, MyApp.Test), or databases for different customers using a SaaS application (like Customer1.MyApp, Cstomer2.MyApp). We don't have that many of those and they are not using LLBLGen (at least yet) so that is not a problem for us. Summing up, unless you have absolutely no new features to implement just leave it as it is .

Best regards, Robert Wilczynski.