The ORM Foundation

Hi Tyler,

I have two versions of this floating that I edited last year, including Win64 support (likely what you're hitting) and VS2010 support. The first version throws columns at the end of the table, the second inserts them after the lead primary key columns. The registry work is incorporated in the .bat files (including 64-bit adjustments).

Edit away, and remember to fully extract the zips and run the install as an administrator or nothing will work.

-Matt

Matt,

I'm probably oversimplifying the problem but would it be possible to create the SchemaName custom property for each enity like Schema and create a SDIL like a schema intermediate file that has just  list of Schema Names, their associated table names, and the current Name of the model that the overall schema falls under that would be replaced only if it has a schemaname other than empty string.

 I guess you have to create a new schema for each new schema name, and then simply replace {OverallSchemaName}.{tablename} instances with the new {SchemaName}.{tablename} if it exists.  I thought the new version would have fixed this b/c I saw that in your notes you added the "Schema" as a new added feature but I have not been able to get this to work yet.  I tried to add table specific schema names without success and maybe I'm just not using the feature correctly.

Hi Marc,

Are you looking for a way to generate multiple schemas? I've previously posted a way to add explicit schema names using custom properties (see http://www.ormfoundation.org/forums/p/573/1698.aspx#1698 for the end of the thread. Minor batch file adjustment will be needed for VS2010/VS2012).

The transformation for adding schema names is much more involved than this one because schema is a parent tag of table in the XML representation, so a major document restructuring is required to do this. The schema name is not just an attribute of the table or a tweak of the name itself.

-Matt

PS The readme for the latest version just says that the schema name (emphasis on 'the', meaning one-and-only) generated for the model could be customized and remembered, like the customize-and-remember feature for table and column names that I added last year. I threw this one in because it was an oversight, and because I was having problems getting a web-hosted postgres db to accept any schema other than 'public'. I guess this is the privilege of both developing and using NORMA: if something small annoys me during use, I can fix it myself:)

Thanks for the info and for establishing what's possible with the orm tool.  I've been fighting with various schemas and trying to find a simple way to add a simple foreign key constraint between schemas.  For me it would be nice if I could just have two orm windows open and add a fact type between the two orm windows between two roles and then just create a totally separate file with just that constraint.  This would save a lot of work for me if there were some way to add that bit of functionality without obstructing or interfering with the underlying code base.

Thanks for share such informative discussion now i can understand the Value Type Group Funda. Thanks Again.