Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
When I first started using NORMA, I was following the Lab .ppt tutorials, and consequently, my diagram was first named by default: ORMModel1.orm
After my project started to take some direction, I saw that the model name becomes the schema name and database owner name and so, I renamed the .orm to something more appropriate to reflect my intended DB owner: SBSSM.
However, the original db owner name was still stuck - my DDL output still had the old schema name and tables such as ORMModel1.Item, etc.
For other newcomers that encounter this issue, the best way to permanently effect the desired dbo name change, is simply to click on an empty spot on a model page and edit the ORMModel properties [-]Misc > Name: to what you want. Simply Saving As... to a new name does not do it.
As a side note, I have several OFT's that I renamed to something more appropriate - so that, for example, "KitItemIsBuiltOfComponentItemInComponentQuantity(ID)" is now simply "Kit(ID)"
Contrary to my expectations, all of these OFT names, without exception, display as intended in both the Relational View and in the DDL output. However, I have one very ordinary entity that outputs to DDL as:
CREATE TABLE ORMModel1."Order"
Althought it looks strange to me, technically, this is not invalid T-SQL, but I don't think those quotes should be there, nor can I explain why they are.
Kevin M. Owen
The quotes are the mechanism used in the ISO SQL Standard to create a "delimited identifier". Microsoft SQL Server works correctly with this, and also supports an alternative (non-standard) notation using square brackets (e.g. [Order]).
Delimited identifiers (as opposed to "regular identifiers", which are just identifiers without quotes or brackets) are used to indicate that a particular string is being used as an identifier, not as what it would normally be parsed as.
They are most often needed in two cases:
1) The identifier contains characters (such as whitespace) that would cause it to not be interpreted as an identifier.
2) The case-normal form (which essentially means the uppercase form) of the identifier is the same as a keyword, which is forbidden.
In this case, the quotes are being added by our generator for the latter reason, since ORDER (as in ORDER BY) is a keyword.
It is possible that SQL Server may handle a table named Order without any problem, since many implementations are more forgiving than the standard requires. However, to be safe (and standards-compliant), we always generate a delimited identifier if the regular identifier form would be illegal according to the standard.
That makes perfect sense! I am again impressed by the foresight and thoroughness of the dev team.