The whole thing started when I tried to modify a foreign key constraint. Then when trying to deploy the package I got an exception saying that a certain field (which is the primary key) could not be renamed because it was a member of a list. I have removed the constraint and add it again, and the same error.

After that I have removed the whole table and recreated it. Not I get four exceptions: One that says that a certain view (which depends on the table) could not be created because the table is not there. I have remove and recreated the view too, but still the same error.

The other two exceptions complain that they cannot verify the existence of the indexes in the table and view which I have removed and recreated.

The fourth complains about not being able to verify the existence of foreign keys in the table that has been removed and recreated.

Is there a chance that I'm doing something terribly wrong with DDT? I have imported the tables from a SQL2005 database and created all indexes and stored procedures and views manually in the DDT. After that all I do is modifying the schema. Is there a certain way I must be using the DDT tool? Is this because DDT is a rather new tool?

I have attached a rar file that contains my database, my StrataFrame database, the package, and the result log files of the deployments, in case you'll need to look more into it.

Thank you in advance.

All views are created after tables...the issue is that your table was in error so that view could not be created.

This is where the issue is....I do in fact have your data, and it deploys just as it should on my servers once I corrected the circular reference relationship....every time on 3 different servers....and it updates after I make a change to your package.  Again, we deploy all views AFTER the tables...you have the source code and your are welcome to verify this yourself.  It is in the DatabaseMigrator class.  We are committed to fixing ALL known bugs...but in this case, from using the samples that you have given me, I cannot see that there is a bug anywhere....sorry for your frustrations here, but I do not beleive that there is a bug related to views and tables in the deployment.  I think that you have an issue with your existing database.  If you deploy to a clean instance (new database) I do not believe that you will experience this problem.

Again, if I could reproduce this same behavior I would fix it...George, I think that we have gotten off on the wrong foot from the very beginning here...it is my desire to help you, but through your emails, your posts, you have been very forceful and in some cases, I feel as though you have been somewhat hostile.  You act as though I am trying to turn a cold shoulder to you here....we NEVER turn our back on any known issue...but just like your application and customers, if they have an issue, you have to first be able to reproduce it and prove that there is an issue before you can fix it....so far this has not been the case.  Now there is a known issue on the import as it relates to User-Defined PKs.  I beleive that you were the one that pointed this out and we are going to look at this (it is in our task list).  But if we cannot reproduce the error, I cannot snap my fingers and produce a fix.  I would really like for you and I to be able to work together to resolve the issues you may be running into instead of making negative accusatory remarks.  If you feel that there is a bug, then the best way to go about this, since you appear to feel that it is related to creation order, is to create a simple package file instead of a full blown deployment package to isolate the problem so that we can then address it.  I hope that you understand my position and that we can work together.  Thanks.