StrataFrame Forum

Field Constraint errors

http://forum.strataframe.net/Topic21966.aspx

By Jason Seidell - 2/13/2009

This is getting frustrating and I hope there is a solution, or maybe this is a new bug???

From the best of my understanding this is what is happening.

1) Originally built and deployed a set of databases with version 1.6.0, did not add any NOT NULL or default value constraints on fields.

2) Some time later, we updated to version 1.6.5.  Started having occasional exceptions when accessing BOs with a field with a NULL value.  So we started updating fields whenever we needed to redeploy the DDT to turn on the NOT NULL option and set default values.

2.1 - When adding these we keep getting DDT errors stating, 'Error, cannot add constraint, 'Fieldname' already exists.  This error is because we have multiple tables with the same fieldnames and the constraints get added with only the fieldname.  However, if we deploy the exact same package to a fresh install the errors don't duplicate because it names the constraints 'DF_tableName_fieldName'.  The only recourse is to deploy, change constraint names, redeploy, change additional set of constraint names, and repeat until it finally adds all the constraints (because after it fails adding the first constraint it stops adding constraints to that table).  So this process can easily take 6-12 times to finally get a clean deploy.  I have tried deleting all the constraints from the database and then redeploy but they just get assigned the same name and still creates the errors.

So I'm totally lost as to what is happening, how to best fix this, and how to keep it from happening again.

Sad Jason

By Jason Seidell - 2/13/2009

I found a similar type problem at this post, http://forum.strataframe.net/Topic9680-11-1.aspx?Highlight=DDT+Errors+constraint

However that is from early 2007, and I would think the problem should be fixed by now....

By Jason Seidell - 3/5/2009

Kinda surprised I didn't get a response from anyone on this...

However I found the cause and confirmed the differing behaviour in the DDT.

It seems when DDT redeploys it does not do a rename on current constraints already on the database.  You can see what the constraints would be named by right clicking on a table->Edit and look at the constraint names in the table create statement.

I found this script to generate a set of update statements to rename all the improperly named constraints, which works nicely.

select 'exec sp_rename ' + o.name + ', DF_' + t.name + '_' + c.name

from syscolumns c

inner join sysobjects o

on c.cdefault = o.id

inner join sysobjects t

on c.id = t.id

where c.cdefault <> 0

and o.name <> 'DF_' + t.name + '_' + c.name

order by o.name

http://www.windows-tech.info/15/6d48dce5e3ef6cb8.php

However, I still have the same problem as before, all the constraints that are added to an existing database the first time are just named fieldname, but if I take the same package and deploy to a new database the constraints are named DF_tablename_fieldname. 

I'm very frustrated at trying to get this working!!!

Any help please!!

Jason

By Trent L. Taylor - 3/6/2009

Jason,

First of all...this post was just missed.  When this happens and if you do not get a response within a day or so, post again out so that it bumps this back up on the list and puts it back on our radar.

As for working through your problem, send us your PKG as well as an MDF or SQL backup of the database to which you are trying to deploy.  This is the quickest way to get to the bottom of something versus going back and forth on the forum.  Finally, have you downloaded the most recent version of hte 1.6.7 beta?  There have been a lot of things fixed within this beta.  This is a stable codebase and actually what we are deploying into the field with our medical software....we just have not finalized the help docs and samples.