TDM should detect database restrictions violations

Often DDL or Alter Scripts are not executable because same database restriction are violated. TDM should detect these and at least warn the user during Verify Model…


  • Oracle max. length for tables and column names 30 characters
  • MS SQL only one clustered index per table allowed


Hi Andreas,

Yes, something is registered as CR (Oracle max. length for tables and column names 30 characters) and something is already verified by default during Model Verification (MS SQL clustered index).

If you have other specific examples, please write us. Either it’s already verified or I will create a new CR for it. Thanks.



No other restrictions at the moment…

A really helpful feature would be some kind of general PDM, that restricts to common features all databases support. So someone could define a model that is easily portable to all supported databases.

A logical model for the same would also be nice. Does anyone have experience with designing in a logical model and convert changes to several physical models? I guess there needs some convertion be done manually?!?


Hmmm - maybe a PDM of database type ANSI ??? Just remember - that could be very restrictive. I like the idea - I just want to make sure that people know if they could and did choose something like this don’t be surprised when stuff you think should work does not. Because NONE of the database vendors stick close to ANSI spec - they all add useful stuff :slight_smile:

Nice idea, but probably to much restrictive.
A much more useful feature would be to have some kind of meta model (your ansi model?) without db specific features, but that is linked to several database specific models. So the idea is to maintain tables, views, columns… in the meta model and all changes reflect to the connected models (some kind of inheritance). In the database specific models you can adjust the database specific properties.

That is exactly what you need to maintain one single PDM that needs to be ported to several database systems.

Perhaps this is easier to implement than one might think: Just add the connection relation from the database model to the meta model and remember the version. Only changes made in the meta model are propagated. After activating the specific model check for a version update in the meta model. Then just apply the changes made in the meta model (use simple model conversion algorithm on the change set)…

Looking forward to see this in the next beta ;-)))
Just my wish for christmas /\