A deployment problem with the GDR release for Database Pro and MSS2008
I am having problems getting my project to deply. When I click deploy the following is all that happens
t------ Build started: Project: DBStorefront, Configuration: Localhost Any CPU ------
Verifying project state.
Finished verifying project state.
DBStorefront -> C:\Amphire.Data\DBStorefront\Localhost\DBStorefront.dbschema
------ Deploy started: Project: DBStorefront, Configuration: Localhost Any CPU ------
Deployment script DBStorefront.sql generated
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========Why isnt it deploying to the database? What can I look at to trouble shoot this?
Risposte
Looks like my problem has nothing to do with my database schema.
I have no idea how my project files were messed up. I am working now so all is good. I played with my project for a while and had trouble re-created my problem. Go figure. If I get more time I will try to go through what I did a step at a time to see if I can re-create my problems.
Tutte le risposte
If you right-click on your project in Solution Explorer, select Properties, and then click on the Deploy tab, what does it show in the "Deploy action" drop-down? It sounds like it is set to 'Create a deployment script' and not 'Create a deployment script and deploy to database'.
Hope that helps.
Its set to 'Create a deployment script and deploy to database'
I also have the 'Always re-create Database' check selected in the DeploymentConfiguration.deploymentconfig.
The only non-standard thing I am doing is H ave created 3 different SqlCommandVariables.sqlcmdvars files. 1 For each configuration I have defined.
I deleted the Debug and Release configurations and added 3 new ones: Localhost,Development and QA. I made sure the 3 new configurations are defined in the solution file and the project files.
I'm getting the same problem with roughly the same type of configuration. It is absolutely set to "Create a deployment script (sql) and deploy to database." It just wouldn't deploy to the server, but it wouldn't error out either.
I switched to the command line of msbuild and I'm getting a warning: "Deploy warning TSD00258: The project and target databases have different collation settings, deployment errors might result.
"Treat warnings as errors" is not checked, so I don't know why a warning would halt deployment.
I put 00258 into the "Suppress Warnings:" box to see what will happen. It didn't make a bit of difference. I've also changed the collation and I've deleted the database from the server I'm trying to deploy to. Nothing.
No errors. Just this warning. No deployments.
Yes, something does not sound right here. In most cases, if a connection string is not defined we will generate an error message saying that a valid connection string was not specified.
Could you post the contents of your *.deploymanifest file? When a build is performed we take a snap-shot of your current configuration and place it in this file. For instance, my deploymanifest looks like this for a simple project:
<Project DefaultTargets="DspDeploy" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetConnectionString>Data Source=(local)\sql2005;Integrated Security=True;Pooling=False</TargetConnectionString>
<TargetDatabase>Database1</TargetDatabase>
<DeployToDatabase>True</DeployToDatabase>
<DeployToScript>True</DeployToScript>
<OutputPath>.</OutputPath>
<DeployScriptFileName>Database1.sql</DeployScriptFileName>
<DeploymentConfigurationFile>DeploymentConfiguration.deploymentconfig</DeploymentConfigurationFile>
</PropertyGroup>
<ItemGroup>
<DeploymentExtensionConfiguration Include="Script.PostDeployment.sql">
<__PostdeploymentMetadata>
</__PostdeploymentMetadata>
</DeploymentExtensionConfiguration>
<DeploymentExtensionConfiguration Include="Script.PreDeployment.sql">
<__PredeploymentMetadata>
</__PredeploymentMetadata>
</DeploymentExtensionConfiguration>
<SourceModel Include="Database1.dbschema" />
</ItemGroup>
<Import Project="C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" />
<PropertyGroup>
<SqlCommandVariablesFile>SqlCommandVariables.sqlcmdvars</SqlCommandVariablesFile>
</PropertyGroup>
</Project>
The two high-lighted options above control the actions taken during deployment. Does deployment work correctly if you just try deploying a project with a “Standard” debug or release configuration?
I created a new project and reimported the database objects for the database was I working on before. This time I didn't create any custom configurations. I just set the Target Connection to a server. This time, I got farther. The deploy started, but failed multiple times because some of the foreign keys that I had just reverse engineered from an existing database (built through the 2008 version btw) had their columns arranged differently than the primary keys with which they were associated. Once I cleaned those up, the deploy succeeded.
I'm going to go on and begin creating custom configurations now to see if I can figure out what I did wrong the last time.
I don't know what went wrong yesterday, but I'm just about back to where I was. I've created three custom configurations and I've got it deploying to more than one server. Thanks for your help.
One question I still have. Where are the connection strings stored? If I check this project into source control and the database developer next to me decides to deploy it, will he see the same server connections that I created for the configurations?
I did some investigation and this is what I found.
In the dbproj file, the DeployToDatabase tag was dorked up. It looked like the following
<DeployToDatabaseAddToServerExplorer>False</DeployToDatabaseAddToServerExplorer>
I have no idea how it got messed up. The deploy worked when I changed the project script and removed
the <DeployToDatabaseAddToServerExplorer>False</DeployToDatabaseAddToServerExplorer>
and replaced it with a
<DeployToDatabase>False</DeployToDatabase>
You have a choice where to store the connection strings. If you look at the deployment configuration page there is a “Configure deployment settings” drop-down. By default it is set to “My project settings” which means the connection string is stored in the .dbproj file. If you change this drop-down to be “isolated environment” we should write the connection string out to the .user file.
The idea (similar to previous versions) is that the .user file is your isolated developer sandbox whereas the project is your team settings. There was confusion about this in previous versions and this is our attempt to make the two different scenarios cleaner.
Can you reproduce this deployment problem? If so, it would be great if we could get a snapshot of the source/target .dbschema files to reproduced/fix the problem.
Looks like my problem has nothing to do with my database schema.
I have no idea how my project files were messed up. I am working now so all is good. I played with my project for a while and had trouble re-created my problem. Go figure. If I get more time I will try to go through what I did a step at a time to see if I can re-create my problems.
Excellent. I just tested it all by setting up a build and checking the project into TFS. I then deleted the entire project off my desktop then retrieved it from TFS. All the settings are still there. YEE HA!
This sure beats checking in the .user file and then checking it out & overwriting the local one every time I wanted to work on a project.
Thank you very much and please pass on to the team that they did a good job. This really makes a difference for us.
Now, when is it coming out?
Cool, glad to hear it is working well for you!
The GDR delivers support for offline development targeting Katmai databases. Right now, we are estimating delivering the GDR ~8 weeks after Katmai is released.
I am actually deploying to SQL Server 2005 and I'm getting this:
Warning TSD00258: The project and target databases have different collation settings
I'm intentionally generating the script only because we just upgraded. However, why do I get this warning when I deploy despite the fact that both DB and project are set to this collation:
SQL_Latin1_General_CP1_CI_AS
The Doctor- Never mind, I figured it out. I had a typo in the target DB name. You will get this warning if deploying to a new DB. It's kind of silly, but not inaccurate since a non-existent DB would have no collation setting.
The Doctor
