We are occasionally asked to change the following two Advanced Options so they are checked by default.

Metadata Class Should Ignore Catalog
Metadata Class Should Ignore Schema

Our current defaults for the C# and VB Generated Classes Master templates and MetadataMap templates are unchecked. What this means, is that, by default, the Catalog and Schema are hard coded into your business objects Metadata class. For example:

meta.Catalog = "Northwind";  <============
meta.Schema = "dbo";         <============

meta.Source = "Employees";
meta.Destination = "Employees";

In some cases, it does not matter how these are set. The EntitySpaces Demo will run against SQL Server, MS Access, MySQL, and VistaDB both ways.

In some cases, these should be checked. If your target is the Compact Framework, these must be checked. If you want your database (Catalog) and schema information to come from your connectionString, then these should be checked. This is a very common production scenario, and when EntitySpaces determines that Catalog and Schema are missing from the MetadataClass, it will pick them up from the connectionString. Each installation of an app can have its own config file which controls what a user has access to.

In some cases, it can be an advantage to leave them unchecked (hard coded). For example, our unit tests take advantage of this. We only need one config entry with one connectionString for SQL Server:

connectionString="Data Source=MyServer;Initial Catalog=AggregateDb;Integrated Security=sspi"

The server not only has Northwind, but many test databases - AggregateDb, SqlTypeTest, ForeignKeyTest, ComplexHierarchical, etc. Because the catalog is hard coded in each business object, we can instantiate any of them, from Northwind Employees to ForeignKeyTest CustomerGroup, and EntitySpaces will generate the correct SQL from the info in the MetadataClass. No need for multiple connections, or switching connections at runtime.

So, whether these are checked or unchecked by default seems something of a coin flip. Our inclination would be to leave well-enough alone. But, since the request has happened on more than one occasion, and the change is a relatively simple one, we thought we would ask rather than try to second-guess what is the most beneficial to the most users.

Each database treats these things differently, and in some cases schema is not supported or generated, regardless of how you check it. Each production environment has its own requirements. If we have overlooked an important pro or con, please feel free to post it below.