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.

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,

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.

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.

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.

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! 

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.

I do see what you are talking about on the deployment now.

The best solution here would be to fix your meta-data in the DDT to line up as desired so that your deployments can proceed without issue. We try to get you as close as possible with the automation on the import, but in your specific scenario the DDT can't decern which index you want to be primary and, as such, is creating two primary index on two tables. In that case, simply delete the one you don't wish to be a primary index and recreate it manually. 

This would be a one time fix on your part, once you have all the indexes limited to one primary index per table within the DDT, your deployments should work without issue from that point forward.

Any update on whether you were able to reproduce the issue ?

Hi,



When you try to deploy the imported tables as is you get this error:



X 9/26/2008 9:11:46 AM   -> Creating index 'IX_TestCustomer_01' failed.

X 9/26/2008 9:11:46 AM   -> FailedOperationException

X 9/26/2008 9:11:46 AM   -> ExecuteNonQuery failed for Database 'TestDB'.

X 9/26/2008 9:11:46 AM   -> ExecutionFailureException

X 9/26/2008 9:11:46 AM   -> An exception occurred while executing a Transact-SQL statement or batch.

X 9/26/2008 9:11:46 AM   -> SqlException

X 9/26/2008 9:11:46 AM   -> Table 'TestCustomer' already has a primary key defined on it.



This is our main concern we have hundreds of tables that get imported like these test tables and to manually fix them all would be too time consuming. How can I get around this problem?