StrataFrame Forum » StrataFrame Database Deployment Toolkit » Database Deployment Toolkit (How do I?) » DDT process errors

DDT process errors

Edhy Rijo — Thu, 25 Sep 2008 10:42:48 GMT

I am starting to use the DDT to update development/production databases but I am getting some errors which I don't have a clue how to fix them. Attached is the log file, and here are some of the errors:

[quote]• 9/24/2008 8:29:42 PM -> Deploying meta-data for database 'Progytech_CommonDatabase'
• 9/24/2008 8:29:42 PM -> Ensuring Filegroups exist on database 'Progytech_CommonDatabase'
X 9/24/2008 8:29:44 PM -> Creating datafile 'Progytech_CommonDatabase' failed.
X 9/24/2008 8:29:44 PM -> FailedOperationException
X 9/24/2008 8:29:44 PM ->   Create failed for DataFile 'Progytech_CommonDatabase'.
X 9/24/2008 8:29:44 PM -> ExecutionFailureException
X 9/24/2008 8:29:44 PM ->   An exception occurred while executing a Transact-SQL statement or batch.
X 9/24/2008 8:29:44 PM -> SqlException
X 9/24/2008 8:29:44 PM ->   The file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\Progytech_CommonDatabase.mdf' cannot be overwritten. It is being used by database 'Progytech_CommonDatabase'.
X 9/24/2008 8:29:44 PM -> The logical file name "Progytech_CommonDatabase" is already in use. Choose a different name.
[/quote]

The database already exist on my ISP hosting server, so I guess I will get this error all the time, but should this be just a warning, because I am not really trying to create the database.

Here is another one which is really clueless to me:

[quote]X 9/24/2008 8:30:46 PM -> Altering table 'ServiceCalls' failed.
X 9/24/2008 8:30:46 PM -> FailedOperationException
X 9/24/2008 8:30:46 PM ->   Alter failed for Table 'dbo.ServiceCalls'.
X 9/24/2008 8:30:46 PM -> ExecutionFailureException
X 9/24/2008 8:30:46 PM ->   An exception occurred while executing a Transact-SQL statement or batch.
X 9/24/2008 8:30:46 PM -> SqlException
X 9/24/2008 8:30:46 PM ->   Implicit conversion from data type datetime to bigint is not allowed. Use the CONVERT function to run this query. [/quote]

I don't have any table which I made that kind of change to the fields, so I don't even know in this table which field is this error related to.

And the last one:

[quote]X 9/24/2008 8:32:14 PM -> Altering index 'PK_ServiceCalls' failed.
X 9/24/2008 8:32:14 PM -> FailedOperationException
X 9/24/2008 8:32:14 PM ->   Alter failed for Index 'PK_ServiceCalls'.
X 9/24/2008 8:32:14 PM -> SmoException
X 9/24/2008 8:32:14 PM ->   Modifying the IsClustered property of the Index object is not allowed. You must drop and recreate the object with the desired property.[/quote]

I have not made any changes to this index at all.

I appreciate if somebody can clarify what am I doing wrong here. At this point I am not able to do modifications to some of my tables with the DDT.

RE: DDT process errors

Trent L. Taylor — Thu, 25 Sep 2008 10:42:48 GMT

Very true because in the case of the FileGroup being created, it actually has to create a physical file on disk. :)

RE: DDT process errors

Edhy Rijo — Thu, 25 Sep 2008 10:20:04 GMT

[quote][b]Trent L. Taylor (09/25/2008)[/b][hr]Yes. It will not affect the data already there as the $dbname$ should be the same name. And if it isn't then you can ensure that it gets deployed as that. As for BO mappings, it has absolutely no bearing whatsoever as the two are not related.[/quote]

Thanks for the explanation, I will play with this.

[quote]Also, if that file doesn't exist on the machine to which you are deploying, then the only other explanation would be that you do not have permissions to create a file at that location.[/quote]

Guess that may be the case, since the creation of the database must be done via the ISP tools, so externally I have not permission to manipulate the database itself, even though, I can manipulate other objects like tables, fields, indexes, etc.

RE: DDT process errors

Trent L. Taylor — Thu, 25 Sep 2008 09:47:38 GMT

[quote]My filegroup name is "Primary" and my database name is "Progytech_CommonDatabase", should I replace the DB name with $dbname$ instead?, if so, will this affect the data already there, and/or the BO mappings should be refreshed?[/quote]

Yes. It will not affect the data already there as the $dbname$ should be the same name. And if it isn't then you can ensure that it gets deployed as that. As for BO mappings, it has absolutely no bearing whatsoever as the two are not related.

Also, if that file doesn't exist on the machine to which you are deploying, then the only other explanation would be that you do not have permissions to create a file at that location.

RE: DDT process errors

Edhy Rijo — Wed, 24 Sep 2008 21:36:26 GMT

Actually I only get the database error when deploying to the database hosted on my ISP web site which is the one used by my customer for now, if I do it to my local database, I don't get the error.

Looking at the help file for $dbname$, I found this:

[quote]

Tip: To include the name of hte database in the filegroup, use the replacement value "$DbName$". For example, if your database is named "MyDatabase" and you want your file group to be "MyDatabase_Primary", then set the filename to "$DbName$_Primary".

[/quote]

My filegroup name is "Primary" and my database name is "Progytech_CommonDatabase", should I replace the DB name with $dbname$ instead?, if so, will this affect the data already there, and/or the BO mappings should be refreshed?

RE: DDT process errors

Trent L. Taylor — Wed, 24 Sep 2008 21:00:16 GMT

This is standard SQL Server...not DDT. Here is what happened. You probably had a database attached to SQL Server and then detached it, not deleted it. This will leave the mdf file on disk. So you then went to redeploy and the mdf was there when it tried to created the file groups gicing you the error. There really is a fie there but that MDF is not attached.

The other possibility is that you are trying to deploy the same DDT profile to the database with the same data file names (not using the $dbname$ tag) which would also cause this problem.

The remaining errors are standard SQL errors as well...but let's go at it one at a time.