By Chan - 2/12/2009
Hi,
Our developers have spent few days to test on DDT and found some unclear issue as below and would like to ask for clarification:
Scenarios
----------
1.Created 1st package to create the db structure and deployment data, and run the wizard to deploy the database.
Then create another new package,2nd package with the same db structure and deployment data to deploy the database
pointing to the same db that have been created using the 1st package.Error will occured(eg:FlexHRDatabase_results.log)
2.Created package using DDT and remove any one of the database from the DDT and deploy the package again.
An error will occured if click deploy the package. This happen even though I have deleted the db deletion history.
3.Import Security table to a database using DDT.When import the security table for the 2nd time to the same database,
it will create another table for all the tables which are defined the table relationship and a message prompt out to inform
that "Relationship name: Relationship with this name already exists in the database".
Then, it will create additional new tables with same name instead of updating to the existing table.This will only occur if the table has relationship. If the table is without any relationship, it will just update to the same table without creating a duplicate new table.
Any ideas? Please advice.
Thank you
|
By Dustin Taylor - 2/16/2009
For 1 and 2, it sounds like you deleted a database in between the first and second deployment without clearing the object name history. That's the most common reason for the type of error you are seeing in your log file. For 3, the security import is only designed to be done once for a databse. You do not need to re-import the tables every time your data changes, the data packages will be refreshed whenever you recreate a deployment package (assuming you don't select "No" when it prompts you to package deployment data).
|
By Chan - 2/16/2009
Hi,
Dustin Taylor (02/16/2009)
For 1 and 2, it sounds like you deleted a database in between the first and second deployment without clearing the object name history. That's the most common reason for the type of error you are seeing in your log file.
For 1, we create a NEW package as a replacement of the OLD one. For example, we create package A, import database A, deploy to customer. After few months later, we lost the package (for example), and at that time, no database structure changes made. Then, we recreate the whole new package, import database and deploy. We expected would able to upgrade the existing database which created using OLD package. However, we hit the error as attached in previous post.
For 2, yes, we did remove the object history. However, the error is still happening.
For 3,the security import is only designed to be done once for a databse. You do not need to re-import the tables every time your data changes, the data packages will be refreshed whenever you recreate a deployment package (assuming you don't select "No" when it prompts you to package deployment data).
OK, we will test on this.
Please advice. Thank you
|
By Chan - 2/16/2009
Hi,
Accidently put my reply in quote, I worry SF Team missed out so that I reply again.
For 1 and 2, it sounds like you deleted a database in between the first and second deployment without clearing the object name history. That's the most common reason for the type of error you are seeing in your log file.
For 1, we create a NEW package as a replacement of the OLD one. For example, we create package A, import database A, deploy to customer. After few months later, we lost the package (for example), and at that time, no database structure changes made. Then, we recreate the whole new package, import database and deploy. We expected would able to upgrade the existing database which created using OLD package. However, we hit the error as attached in previous post.
Beside, if I have existing database that already deployed to customer, can I use DDT to upgrade them in the future since it is not created by DDT?
For 2, yes, we did remove the object history. However, the error is still happening.
For 3,the security import is only designed to be done once for a databse. You do not need to re-import the tables every time your data changes, the data packages will be refreshed whenever you recreate a deployment package (assuming you don't select "No" when it prompts you to package deployment data).
|
By Dustin Taylor - 2/17/2009
The is used DDT daily by us and many of our customers in exactly the manner you are describing, so I still think it is something in your package(s) or in your environment, I just can't say exactly what based solely on the description you gave and the error log. Can you load the new beta build, re-generate your DDT package and send it my way? I'll try deploying it a few times to a local database to see if I can re-create your behavior.
|
By Chan - 2/17/2009
Hi,
I am not able to upgrade now as we are rushing for a project, and new beta required regeneate all BO.
Anyway, I have attached our package here. Please try it.
Thank you
|
By Chan - 2/17/2009
I have sent the attachment to Trent via PM.
Thank you
|
By Chan - 2/17/2009
Hi,
I have download the latest beta build, and try the following steps
1. Create new DDT profile
2. Import VfsLocalization database.
3. Run Deploy to Server. Target database name is VfsLocalization as well.
4. Error occured as below.
This is to test whether DDT support to "continue" deploy pre-existing database for upcoming release.
Please advice. Thank you
• 18/02/2009 7:52:24 PM -> Deploying meta-data for database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Ensuring Filegroups exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Filegroup verification complete.
• 18/02/2009 7:52:24 PM -> Ensuring Tables exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Table verification complete.
• 18/02/2009 7:52:24 PM -> Dropping unneeded filegroups for 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Unneeded filegroups dropped on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Ensuring Indexes exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Index verification complete.
• 18/02/2009 7:52:24 PM -> Ensuring Foreign Keys exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Foreign Key verification complete.
• 18/02/2009 7:52:24 PM -> Ensuring Triggers exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Trigger verification complete.
• 18/02/2009 7:52:24 PM -> Ensuring Assemblies exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Assembly verification complete.
• 18/02/2009 7:52:24 PM -> Ensuring Views, Stored Procedures, and UDFs exist on database 'VfsLocalization'
X 18/02/2009 7:52:24 PM -> An error occurred while creating the stored procedure [dbo].[MessageItemsInsertOverwrite].
X 18/02/2009 7:52:24 PM -> SqlException
X 18/02/2009 7:52:24 PM -> There is already an object named 'MessageItemsInsertOverwrite' in the database.
X 18/02/2009 7:52:24 PM ->
X 18/02/2009 7:52:24 PM -> Source : .Net SqlClient Data Provider
X 18/02/2009 7:52:24 PM ->
X 18/02/2009 7:52:24 PM -> Stack Trace:
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
X 18/02/2009 7:52:24 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.DeploySprocsOfPriority(Database parent, DatabaseInfo dbInfo, Int32 priority)
X 18/02/2009 7:52:24 PM ->
X 18/02/2009 7:52:24 PM -> An error occurred while creating the stored procedure [dbo].[MessageLanguagesInsertOverwrite].
X 18/02/2009 7:52:24 PM -> SqlException
X 18/02/2009 7:52:24 PM -> There is already an object named 'MessageLanguagesInsertOverwrite' in the database.
X 18/02/2009 7:52:24 PM ->
X 18/02/2009 7:52:24 PM -> Source : .Net SqlClient Data Provider
X 18/02/2009 7:52:24 PM ->
X 18/02/2009 7:52:24 PM -> Stack Trace:
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
X 18/02/2009 7:52:24 PM -> at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
X 18/02/2009 7:52:24 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.DeploySprocsOfPriority(Database parent, DatabaseInfo dbInfo, Int32 priority)
X 18/02/2009 7:52:24 PM ->
• 18/02/2009 7:52:24 PM -> View, Stored Procedure, and UDF verification complete.
• 18/02/2009 7:52:24 PM -> Ensuring Indexes exist on database 'VfsLocalization'
• 18/02/2009 7:52:24 PM -> Index verification complete.
• 18/02/2009 7:52:24 PM -> Finished verifying databases on server.
• 18/02/2009 7:52:24 PM -> The meta data conversion to the SQL Server has been completed.
|
By ChanKK - 2/18/2009
Hi,
Just would like to inform that, my personal account "Chan" has been expired (since no longer able to post any message). I would use this account "VisualSolutions" to reply my post.
Anyhow, I still waiting for SF reply.
Thank you
|
By ChanKK - 2/18/2009
Hi,
I have gone thru DatabaseMigrator source code, found that the error below occured caused by the priority of stored proc "MessageItemsInsertOverwrite" in pre-existing database is NULL, therefore filtered by DatabaseMigrator. We never specify priority when create sp. Question is, why does it required? Anyway to not filter it?
Please advice. Thank you.
X 18/02/2009 7:52:24 PM-> An error occurred while creating the stored procedure [dbo].[MessageItemsInsertOverwrite].
X 18/02/2009 7:52:24 PM-> SqlException
X 18/02/2009 7:52:24 PM-> There is already an object named 'MessageItemsInsertOverwrite' in the database.
|
By Dustin Taylor - 2/19/2009
The priority is required, but it should not be deployed with a null value. The default priority for stored procedures is 10, and should be at least 1 if edited, so it set to NULL after deployment it is an erroronious state. Try deleting the erronious stored procedure via SQL management studio and see how that affects the deployment. If you can create a package using the new beta build that consistently deploys a sproc with a null value then by all means attatch it here, I'd like to be able to get in and give you a more specific answer. As it stands however, I can't deploy the package you sent to Trent for the reasons I already listed. We can't deploy a DDT package created on versions of Strataframe prior to the current beta build due to structure changes in the package file. Sending me the old package file does no good as I can't deploy it on my side. My guess is that the deployment failed in the past and left the orphaned sproc out there which is giving you the problems, but I can't confirm this based soley on log files.
|
By ChanKK - 2/19/2009
Dustin Taylor (02/19/2009)
The priority is required, but it should not be deployed with a null value. The default priority for stored procedures is 10, and should be at least 1 if edited, so it set to NULL after deployment it is an erroronious state. Try deleting the erronious stored procedure via SQL management studio and see how that affects the deployment.
No, the pre-exsiting stored procedures are not created using DDT. They are created using CREATE PROCEDURE command, which maintain by us before using DDT. Beside, I found that, the priority field is extended property added by DDT, and not standard SQL Server field. Therefore, any SP deployed previously (not using DDT) would not have any value on it. That is the reason for the error. Do you think this is a "limitation", which need to be enhanced? Or, do you think DDT would not support to deploy any SP which previously not deployed using DDT?
Please advice. Thank you
|
|