On your first problem, what steps are you taking to reproduce the problem? You said it happens on deployment data packages that you've already added, and then you're tring to add them a second time?
1. Start with a profile that contains database and data deployment packages for the security tables only. Modify the security data deployment packages to extract all security records from my development application database.
2. Everything works as it should; I can click on ‘create a package” as many times as I want and the package builds successfully.
3. Add a new data deployment package that extracts data from a table in my development application database.
4. Click on create package, package build is successful
5. Click on create package a second time, the build fails with event ID: 1026
I just tried it again and I’m getting a different message.
-Larry
I could not reproduce this so I recompiled the EXE to show the stack track in the message. This should give us more information as to how to resolve the problem. Just copy the EXE and the DLL to the following folder:
c:\program files\microfour\strataframe\
(You should see the existing files in this folder)
Overwrite them and run this again and then you can see the stack trace. Let me have the stach trace and hopefully this will get us going in the right direction. Thanks.
It looks like this may be coming from your how your relationships are trying to gather the data. The bottom line is that the foreign key table is being added to the collection more than once. In other words, I think you have a relationship established that brings in a child table more than once. You can get around this problem by changing the children levels and then manually bringing in the table causing the problem.
By default the children levels are set to infinite which will try to find all of the child relationships and bring in that data. Reduce this number to prevent any overlapping of children tables....you may have to bring in the children tables by themselves.
Trent,
Setting the Children Levels to None eliminates the Event 1026 error. However the version of DDT you provided that includes the stack trace introduced the following error when you go to deploy the package.
Reverting back to the 11/27/2006 compiled source code eliminates that issue. However there is still the problem of deploying data that includes a timestamp column.
As for the other error, this is probably accurate because we changed the way data gets deployed to support Vista. I did not give you the framework DLLs so the DatabaseMigrator class is reading the package file differently. For now, definitely revert back to your older version as the new data deployment has changed. The EXE I gave you is packaging up the data for teh new format and your DbEngine DLL is trying to deploy on the old format. Make sense?
Got it on the “Unable to read beyond… “ error message. I’ve reverted back to the previous version.
On the timestamp issue I believe the source of the error is that DDT is trying to insert the timestamp value from the source table defined in the data deployment package into the target table, which is not allowed. You also cannot specify a default value for data type timestamp. SQL timestamps are automatically generated and inserted/updated by SQL Server database engine. The data deployment package should be ignoring columns defined as timestamp data type and simply insert the remaining columns into the target table. The database engine will take care of inserting the timestamp on the new rows.