Like this infographic? Get more content marketing tips from Copyblogger.
Monday, January 20, 2014
Friday, December 20, 2013
Database Deployments with SSDT–Data File Sizing
I recently ran into an issue when migrating a database from DataDude to SSDT in Visual Studio 2012. No matter how hard I tried I could not get the deployment, actually I should say Publish now, to honor the sizing that I defined. For example: I defined a data file that I assigned to PRIMARY as the only data file for this database. I made sure to add the File Size and File Growth properties like a good DB guy should, yet when I generated the create script they were just not there. Here is what I included in the project
ALTER DATABASE [$(DatabaseName)]
ADD FILE
(
NAME = [MyApplication],
FILENAME = '$(DefaultDataPath)$(DefaultFilePrefix).mdf', SIZE = 50MB , FILEGROWTH = 100MB
) TO FILEGROUP [PRIMARY]
However here is what the publish output looked like:
CREATE DATABASE [$(DatabaseName)]
ON
PRIMARY(NAME = [MyApplication], FILENAME = '$(DefaultDataPath)$(DefaultFilePrefix).mdf')
Where are my file settings? How is SSDT ignoring my commands and why would it be doing this? As it turns out this is expected behavior and it is controlled by a couple of settings.
Open the publish file within SSDT and click on the Advanced settings button. Scroll down to find “Script File Size” option which is OFF by default. This setting controls what SSDT does with the 3 properties exposed when creating a data or log file; Size, Maxsize, and Filegrowth. Checking this value will cause SSDT to script those properties on publish.
Now there are a few reasons why this is set to be off by default and you can see the explanation here.
The main reason is that by default you would not normally want a production sized database on your Sandbox/ local development machine, makes perfect sense and this is a great option.
Of course during an automated build process you should pass in this Script File size property set to TRUE so SSDT and your build process will honor your file size settings – better still make the sizes properties so you dynamically set them for each build and target!
Monday, October 21, 2013
Changing save location for draft posts – Windows Live Writer
While stating out using Windows Live Writer -http://www.microsoft.com/en-us/download/details.aspx?id=8621 – a tool that allows you to create drafts of your blog posts without knowing HTML in an easy to use client side application – I immediately found a need to change where my drafts were saved. The goal was to create drafts and save them to a shared location where I could easily review them later. The first location that came to mind was my Dropbox folder, unfortunately there are no built in options for changing this. I tried to do the registry hack found here but was unsuccessful so I continued my search. I ended up by finding a solution that works by using “Symbolic Links” http://en.wikipedia.org/wiki/Symbolic_link
Check out the solution here: http://www.cto20.com/post/Tips-Tricks-Customize-the-Location-of-Windows-Live-Writere28099s-e2809cMy-Weblog-Postse2809d-Folder.aspx
Thank you Antonio!
The First Post with Live Writer
Here is the first post using Live Writer – http://www.microsoft.com/en-us/download/details.aspx?id=8621 -a tool for composing blog posts in an easy client side tool. Why am I trying out Live Writer? Well for starters I wanted a way to write a post and save it for review later. I find that I actually enjoy reviewing and editing things, from code snippets, designs, even online blog posts. Quickly writing content and storing it away for later in my online blog just did not seem easy and I find that actually submitting a post triggered a mental button in my head to fire that said “I am done with this…move on”. The ability to review what I write is important. For starters it will limit the emotional reaction posts that can get me into trouble and reviewing for correct content is never a bad thing.
Technorati Tags: Windows Live Writer,easy blogging tool
Get blogging again will ya!!
As suggested by the very wise Andy Leonard (http://sqlblog.com/blogs/andy_leonard/) I am going to give LiveWriter a try. I downloaded the bits from http://www.microsoft.com/en-us/download/details.aspx?id=8621 and began the install process but I soon ran into an issue. It seems I had some older Windows Live applications on my machine which the install was not too happy about. I uninstalled all Windows Live programs and tried again - Lets see how this goes. Hopefully next post will be with Live Writer.
Thursday, February 16, 2012
I am currently working my way through some PowerShell scripts for finding and removing old SQL backup files that have been hanging around for sometime now. The automated process that creates these backup files does only keep a certain number of files that are a certain number of days old, however this process is not fail safe and it will leave around older backups. I am working to keep the total number of files around to a minimum so I am implementing this process in PS. Here is what I have so far...
$dirs= dir -Path \\server\SQLbackup\* -Recurse | Where-Object -FilterScript {($_.fullname -notlike "*Blah*") -and ($_.psIsContainer -eq $true) -and ($_.fullname -like "*servername*") }
foreach($dir in $dirs)
{
#write-host $dir.fullname
$fs= Get-ChildItem $dir.FullName -Recurse | Where-Object {(-not $_.PSIsContainer)} | Where-Object {($_.LastWriteTime -lt (get-date).adddays(-60))}
foreach($f in $fs)
{
write-host $f.fullname
}
write-host "Deleting File $File" -foregroundcolor "Red";Remove-Item $File.FullName |out-null
}
This just simply starts at a root directory and looks for all files that have a folder name NOT LIKE Blah, it has to be a folder, and must have the root name of all my servers in the path. Then it gets all items where the lastwritetime is older than 60 days. for each one of those it issues a Remove-Item command on the FULL name.
Some issues here...
$dirs= dir -Path \\server\SQLbackup\* -Recurse | Where-Object -FilterScript {($_.fullname -notlike "*Blah*") -and ($_.psIsContainer -eq $true) -and ($_.fullname -like "*servername*") }
foreach($dir in $dirs)
{
#write-host $dir.fullname
$fs= Get-ChildItem $dir.FullName -Recurse | Where-Object {(-not $_.PSIsContainer)} | Where-Object {($_.LastWriteTime -lt (get-date).adddays(-60))}
foreach($f in $fs)
{
write-host $f.fullname
}
write-host "Deleting File $File" -foregroundcolor "Red";Remove-Item $File.FullName |out-null
}
This just simply starts at a root directory and looks for all files that have a folder name NOT LIKE Blah, it has to be a folder, and must have the root name of all my servers in the path. Then it gets all items where the lastwritetime is older than 60 days. for each one of those it issues a Remove-Item command on the FULL name.
Some issues here...
- For big directories it is somewhat slow.
- If by some chance the directory name to search on is invalid or not accessible then it will resort to local drives - that is VERY bad because this would delete those files.
- Perhaps sending the initial output to a file then reading that file back in would be safer - at least I could examine the results before deleting.
Subscribe to:
Posts (Atom)