Well, I couldn't wait so I remoted in to my box at the office, copied the dlls to the GAC, tried again and its still trying to create defaults with field name.



Let me back up.... this is for a database that we originally created using default objects bound to the columns. When we realized that these type of defaults were not supported by DDT I created a script to remove these defaults and bindings, imported the db into DDT again and got all the defaults set as literal constraints. Now I am having this problem trying to push the new type of default constraints out to our dev/staging db. The PK's seem OK as I don't have PK in my field names for those so when PK_ is added those are already unique. So its just normal column defaults I'm trying to get set correctly. We are in the habit of assigning defaults to every column rather than knowing for certain anything adding records will have defaults for each column (thus avoiding NULL constraint errors). Its pretty critical we get this working because this is for an app that will be using local SQL Express databases and we don't want to be making special scripts or having to have someone visit each workstation to apply db changes. We already have this app in the clients test environment on a couple workstations so its a good time to make sure these deployment issues are taken care of.

So I think I'm down to just these default constraint issues at the moment.

Hmmmm.....give it a shot because I don't think that you are having a DDT related issue.  It sounds more like a permissions/missing or out of sync assmebly issue.  Let me know if you don't get it working.

Just tried again and still getting name conflicts.



Would the databaseDTK.exe have anything to do with this? Is there a maintenance release for this as well?



Again, just to clarify, in SQL if I create a default the constraint is created with DF_TableName_Fieldname - which is what I want. But, if I'm creating the default in DDT and then push my changes out using the package deployment wizard it tries to create the constraints just using fieldname and then has name conflicts. See attached.



Primary keys and their default constraints seem to be working fine. These appear to just be the defaults on normal columns and foreign keys.



Thanks,

Randy

I take that back about the PK defaults working correctly. I dropped the newid() defaults from one of these which must have already existed from my original db script, re-ran the deployment wizard and it re-created these constraints with only the fieldname as well. The PK_ key/index seems to be named correctly, however. So basically, all defaults are not creating the names the way SQL Management studio does. This is a pretty huge issue for us at the moment... I guess I'm willing to go to 1.6.5 if you think that's my best option at this point. We have 3 other SF developers working on different projects using the same strataframe project db so I have to make sure I co-ordinate with them. Just was hoping would not have to do this since it will force us to do full regression testing. This project falls under FDA regulation guidelines so lots of red tape for every change.

I think that you are mistaken on how we set defaults.  We do in fact set defaults in the same manner as SQL Server.  So I was a bit confused what you meant by that and how you think that this is part of your deployment issue.

I don't know that moving to 1.6.5 would make a difference right now in this case.  We have a version of our medical software in the field that has been installed to over 500 sites using the version of the DDT and DtabaseMigrator (DBEngine) to which you are referring...so I know that it works.  Now, with that being said, like anything else, there are times when we have to deal with certain IT guys who just want to be difficult and think that the server is "theirs" instead of the customers and will tighten down the permissions, play with the structures, etc. and things like this may crop up.

In your case, I think that it is not the latter, but rather something within your package file.  If you just open the AtlasData table and resave the file, it should re-create your PK index.  I would be curious as to what it looked like before and after the save.  If you'll notice, there is a error regarding the SetupKey...is that your PrimaryKey field name?  It acts as though the column is defined more than once within the PK...so that would be the first thing I would look at. 

Past that, I will just need your package file so that I can see what is wrong for myself.  Obviously I would be importing it into a more recent version of the DDT, but I don't think that is what you are fighting.

This is not a permissions issue. And again, the PKs indexes are OK and I know about going in and touching these in DDT first, but the default constraint is being created without the DF_tablename as well.



I have a SQL2005 database in development. It matches EXACTLY what I have in DDT (because I imported from it) except for it doesn't have defaults on the non-PK fields. So, in DDT I simply went through and assigned default values. 0 for int, decimal. empty string for varchar, etc.

When I try to deploy back to the same DB that I imported from in development, I get these errors because I have field names that are the same name but in different tables. Maybe this isn't the best design, but these values do represent the same "thing" as far as the application is concerned, so it makes sense to me. Setupkey is a PK on one table but a foreign key in others. But, because of this, the constraint names are not unique - it doesn't matter that they are in different tables. SQL will not allow a constraint to have the same name as another object in the database.



DDT is NOT work like SQL. In SQL Management studio if I put a default value on any of these column it creates the corresponding constraint with DF_tablename_fieldname, thereby making the object name unique across the database. DDT just uses the field name. I don't think I should have to rename my fields just to use DDT. Again, the idea is to not have to touch these local SQL Express databases with scripts, etc. going forward so I'm trying my darndest to get DDT to work for us before this app goes into production.



I would prefer to email you the SQL scripts and DDT package. There are 2 scripts. One to create the DB as we have it deployed in our clients test at the moment, and another to strip the old type of defaults out (we were using the programmable default types before which apparently is not best practice anymore) Then, if you deploy the DDT package I have against this where I have added the literal defaults you will see what I mean. I don't know what else I can do at this point but if we can't resolve this and I have to script stuff still then DDT doesn't seem like it will work for us long term which would be a shame because other than this problem it seems promising that it could really cut down on deployment issues.

Just FYI for those reading this post, there were issues with the profile and how the database from which the profile was imported came in.  We have been dealing with this via email and PMs.  I figured that there would be some curious individuals

Can't believe it... you caught me! How do you do that?

Trent is trying to help me but we don't seem to be getting to the heart of the problem. If anyone else cares to test the following scenario (I've re-produced in 1.6.6) and can confirm or explain the issue better than I maybe we can get this resolved with some community help:



Create a new database in SQL 2005.



Create 2 tables with a PK and a few other fields – name the non-pk fields the SAME name and make the same type in both tables. DO NOT ADD defaults to the non-PK columns. Import this database into a new DDT project.



Add defaults to all of the non-PK fields in DDT, such as (‘’), etc.



Attempt to deploy this package to the existing SQL database.



You WILL get an error on the 2nd table when it tries to create the default constraints due to it using the field name rather than df_tablename_fieldname. Now, if you deploy this same DDT package to a new database, the constraints are created using the proper naming convention and these errors do not occur. However, we are trying to update an existing deployed database (actually, multiple local SQL Express databases) so re-creating the database to add the defaults is not an option and we're trying to avoid having to create scripts to do this.

What are you defining as a PK field here...that could be the problem here.  Yesterday when I looked at your structures, you had unique clustered indexes, but no primary keys.  Do you have your PKs set as identity columns?  Is this the step I am missing here?