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.

I never had any intention of sounding hostile. Sorry if this caused us any problems. If you go back at the beggining of this topic you will see that I only wanted to help you fix something that looked like a bug to me. This is why I send you my database. Cooperation was always my intention, not boxing.

Also this "misunderstanding" might be the result of my poor english (as I told you before). English is not my first language, I am not familiar with expressions, and most of the time my English words are just translations of my Greek thoughts

I understand your position completely, and I would like to work with you. I found a very good framework in Strata, and would really like to help you make it better.

I will try to send you a smaller project that reproduces the IsClusterd problem.

I have created a small sample DB as I promised.

Attached you can find two packages I have created with DDT. IsClusteredDB_V1 will create you a DB with a single table which contains two columns. One of them is a primary key. This is first version of the DB. The primary key constraint always creates an index in SQL server, which by default is a Clustered index. The first package works fine. In the attached rar, you can also find if you like, the log file of the run.

After that, using the DDT, I have removed the IsClustered property from the primary key index, created a second index (IX_FullName) on the second column of the table, and marked this new index as clustered. This is package IsClusteredDB_V2,and it is the second version of the DB. If you deploy the package you will get two exceptions. The cause is in the first exception. The IsClustered property is not just a property. In order for this property to be set or cleared from an index, the index must be dropped and recreated. I think you have to deploy this property differently.

In the rar file you can also find the log file of both runs.

I hope those can help you reproduce the error and fix it.

Thank you.

I guess that this is the ONLY post that you had posted on related to the DDT that I didn't add another post.  This has already been changed and you can get the update from here: http://forum.strataframe.net/FindPost14258.aspx .  There is a setting on the table that allows you to indicate whether you want to the primary key index to be created on structure saves or not.  Uncheck this setting and you can then create the index as you like.  I also changed the way the import works and used your database to test from.  All of your issues (on the import) stemmed from using user-defined data types.  So the DDT import now looks up the user-defined data type and uses the primary root data type as the type that gets imported.