We appreciate you taking time in looking into this. We considered implementing your solution. But in our schema, it is not going to be practical. We have 1700 indexes to manually delete and recreate. Is there any other option you have to automate this process of deleting an index and recreating as a non-primary index?

We are even open to manually changing your DDT files (if they are in XML format or any such format?)

We would love to use your tool but for this initial hiccup of getting a clean definition.

Since we have 1700 indexes to mark as unique, not as primary, we are trying to automatically correct the definition

This is what we tried.

1. We packaged the definition to a .pkg File.

2. We extracted the Indexes.xml file alone to an output folder

3. We deleted the Indexes.xml from the package

4. In the extracted indexes.xml, we manually corrected the value of idx_type element to 1 from 0. (We inferred that 0-Primary, 1-Unique, 0-Index)

5. We added the edited indexes.xml into the package

6. Now when we try to extract the same file again or import a new database defintion from this deployment package, We get an error. (Key already added to a dictionary..blah blah blah..)

Could you please confirm is this a plausible way of accomplishing what we want? Are we close? What are we missing?

Any Help is deeply appreciated! 

Yeah, fixing 1700 manually would take a while, wouldn't it . Trent is re-building the install to include a change we just made to the DDT to handle this for you. We added a check box to the SQL import that you can uncheck to prevent that second index from being flagged as primary. 

The problem manifests because we check both on the IndexKeyType of the imported sql schema, and on the column states (since the IndexKeyType isn't 100% reliable.)  Since your second indexed "looked" like a primary index, it was getting brought in as a second primary index, which caused the issue on the deployment. In your scenario, unchecking the new "Unique Inddex w/ Entitiy Column is Primary" check box in the SQL Database Import will prevent this from happening.

We'll post the new build in the Posted Releases section once it is finished packaging, and I'll put a reply here as soon as it is up.

The new release is posted [url="http://forum.strataframe.net/Topic19902-22-1.aspx"]here[/i]. Load that and re-try your import. Be sure to uncheck the "Unique Inddex w/ Entitiy Column is Primary" check box from the SQL database options when you run the import wizard.

Thanks very much for the quick turnaround. We downloaded the fix and tested it on a test database and it worked!! We appreciate your support.

Hello,

I know have the DB imported correctly. My next test was to deploy the newly imported structure to an empty SQL db. I now get an IndexOutofRange error. I have attached a screen shot.

Thanks,

This actually is not a bug but rather how you are attempting to gather data in one of your data deployment packages.  The first thing I would recommend is removing them (data deployment packages) or look at your queries and make sure that you are pulling legal data that matches the strucures, etc.  If you do not know which one is causing your problem then just remove them one by one until the error goes away and then add it back so that you have a firm understanding of which data deployment package is causing your problem.