I created a profile from my VFP database and successfully deployed all these tables into a SQL Server 2005 database, including a PK and default value of NEWID() on the field CID ( UID )



There are about 100 tables, all have a pk named CID



As a test of my understanding of the DDT, I added a timestamp to the first 5 tables in the profile ( Timestamp datatype Timestamp NULL )



I did not see any option for only deploying some tables so I answered yes to create a package and deployed to server.



It appears the timestamp was added to the first table but after that the alter failed saying there was a constraint problem CID already existed ( see screenshot attached. ) and this error was repeated for every table in the database.



Obviously I'm missing a key concept here. Is there a problem with key fields of the same name with DDT or am I doing something else wrong ?



TIA

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?