Comments
Sort by recent activity
Great, thanks!
At some point I would like to use the new /include:StaticData feature because it'll help speed up our deployments. Am I going to run into the same error if I try to use that with my filter files? / comments
Great, thanks!
At some point I would like to use the new /include:StaticData feature because it'll help speed up our deployments. Am I going to run into the same error if I try to use that with my...
Hi, I apologize if my reply is untimely. We've had CI running with CruiseControl.Net for quite some time now. CCNet calls a NAnt script which does some Subversion stuff (check out the database scripts, etc.) and then calls the Redgate tools to sync the databases.
It works pretty well now, but we did run into some problems along the way. I hoped we could just sync the schema then the data, but it wasn't that simple. We eventually ended up with a 5-step process to sync the database to SVN.
I detailed the steps in another post so I won't copy it here. I'm not sure that it's the best way to do CI, but it works for us. / comments
Hi, I apologize if my reply is untimely. We've had CI running with CruiseControl.Net for quite some time now. CCNet calls a NAnt script which does some Subversion stuff (check out the database sc...
I'll check it out, thanks! / comments
I'll check it out, thanks!
We're using CruiseControl.Net and NAnt scripts to do our deployments. We have a couple CI environments that are set up to deploy whenever someone commits to Subversion.
Our staging environment is the last step before production and deployments are done a little differently. First we baseline it to match Production (by deploying Trunk; we keep trunk in sync with production) and then we deploy the entire release branch to the staging environment. Sometimes if a deployment fails or we find bugs, we need to redeploy, which involves first deploying Trunk and then deploying the branch again. I'm curious if the migration scripts will get deployed again in this scenario (we would like them to be). Update: I tested the above scenario, and it seems that the migration scripts do not get run the second time. I could probably get around this by changing the property so it reflects the first revision of the branch before we do the sync. / comments
We're using CruiseControl.Net and NAnt scripts to do our deployments. We have a couple CI environments that are set up to deploy whenever someone commits to Subversion.
Our staging environment is ...
Hi guys,
I've been using SQL Compare and SQL Data Compare to do our continuous integration for a little over a year now, and we too have been finding an increasing need for migration scripts so I'd love to get them working.
I tried following the steps outlined in this thread, and I'm getting an error saying "Using source controlled databases requires SQL Source Control to be installed." I'd be interested in hearing the "hacky" way of running this without SQL Source Control since I'd prefer not to install that and SSMS on our build server.
I'm thinking that we should ideally expose the repo using a command line switch rather than relying on the xml file.
I'd like to cast a vote for the command line feature. We use the command line for all the other parameters so that would work nicely for us. (The XML file is workable, though slightly less convenient.) / comments
Hi guys,
I've been using SQL Compare and SQL Data Compare to do our continuous integration for a little over a year now, and we too have been finding an increasing need for migration scripts so I'd...
We've never used a CS database, not sure why it would suddenly be an issue. The source is just a folder of scripts that we check out from Subversion. Also, it's weird that it works fine in version 9 but not in version 10. / comments
We've never used a CS database, not sure why it would suddenly be an issue. The source is just a folder of scripts that we check out from Subversion. Also, it's weird that it works fine in versio...
Nope, we're not specifying that command line switch. (nor /cs, the shortened alias.) / comments
Nope, we're not specifying that command line switch. (nor /cs, the shortened alias.)
You're right, this does look like a case sensitivity issue. The script that SQL Compare generates is trying to add the new column in all lower case and then drop the existing column which is all uppercase. We're using a case-insensitive collation though, so this doesn't make any sense, and it throws an error.
Just for kicks, I tried adding CaseSensitiveObjectDefinition to the command line options (we don't use project files) and I still get the error. It seems like SQL Compare is enabling that option by default. Is there a way to explicitly tell it to do a Case Insensitive comparison? / comments
You're right, this does look like a case sensitivity issue. The script that SQL Compare generates is trying to add the new column in all lower case and then drop the existing column which is all u...
Ah, looking at this more closely has made me notice something.
I ran TCPView and netstat together to compare the results. I saw that one particular port was reported as belonging to SSMS by netstat, but was showing up as a [System Process] according to TCPView.
What's happening is that the port for SSMS is continuously incrementing. When it changes from e.g. 50000 to 50001, then port 50000 gets changed to a [System Process] with the state TIME_WAIT. If I turn the update speed to 1 second, sometimes I see a new port open up for SSMS with the status SYN_SENT which quickly changes to ESTABLISHED. The old port goes from ESTABLISHED to FIN_WAIT1 briefly before changing to TIME_WAIT under [System Process].
All of these connections are to our Subversion server, by the way.
Is it constantly opening and closing connections? (Sorry, I'm not a network guy, I don't know how to interpret this data.) / comments
Ah, looking at this more closely has made me notice something.
I ran TCPView and netstat together to compare the results. I saw that one particular port was reported as belonging to SSMS by netsta...