Author: way0utwest

Team-based Database Development with Version Control
An efficient development process requires that all of your team members coordinate their efforts. This session shows how a version control system (VCS) and standard development practices help improve the speed and quality of your development process.

This talk will look at:
- reasons for using VCS
- methods for including a database in version control
- how we share changes from a VCS
- linking static data in VCS
- enforcing standards in development
Length: 60-75 minutes

Slides:
- SQL in the City: Team-basedVersionControl_SITC.pptx
September 27, 2013
Filestream needs MAX

I wrote today’s Question of the Day for SQLServerCentral on Filestream. I asked which data type was needed for Filestream data, and gave a few choices. Someone pointed out that I wasn’t complete in my choices, and that was by design.

Filestream is an attribute placed on a column, not a datatype. Why it couldn’t be a datatype, I’m not sure, but that would have saved some confusion. In any case, there’s only one data type that can take the Filestream attribute, and that’s varbinary(max). Not varchar(max), not varchar, and not variant. There isn’t, of course, a FILESTREAM type.

However I didn’t want to include MAX since I thought it might sway people towards varbinary, and I was really hoping to teach people, not have them guess. I supposed I could have included MAX with all types, but to me, the (MAX) is also an attribute for the type.

I think it’s a good question, but if you disagree, let me know. Writing better questions is something I want to do to help the community learn.

September 27, 2013
Scripting

One of the directions in which Red Gate Software is to build more tools and utilities that all of you can use for working in cloud environments. We aren’t ignoring the desktop tools like SQL Compare and Prompt (v6, yeah!) that you’ve come to appreciate and depend on, but we are investing in expanding these tools to work with a remote, services style architecture since there are plenty of companies looking at AWS, Azure, or other providers for a portion of their applications.

I’ve been learning a bit more about the way cloud services work and one of the things that becomes important in an IaaS environment is scripting. The environment you get is a base install and if you need more software or processes to run when a new VM starts up, you need to script the various installations or configurations.

There are some great scripting features for SQL Server, like Finebuild for installs and Powershell for most everything else. Scripting is a great way to accomplish tasks, but like most skills, it needs to be used in order to be efficient and practical for most tasks. I’ve struggled with this, and I’m sure many others feel the same way.

However I am starting to think that Powershell might be the best investment in my future skills. The quicker I can write it and build scripts to accomplish tasks, the more I’ll be able to do over time as I build a library of commandlets and scripts. That’s if I remember to document them well so I can easily search for what I need.

September 26, 2013

It Happens

Your code is wrong.

Or it’s bad, or it won’t work as intended. I’m not sure that’s the viewpoint I’d like to take when I first start working on a project, but that’s what Nathan Marz told the attendees at the NoSQL2013 conference recently. He says that our code should be treated as something that might or might not work, and we should embrace the idea that the code can be wrong. It’s not intended to disparage developers or paint too bleak a picture of our skills, but to just be realistic in the sense that all projects have problems and software isn’t perfectly built at the first compile.

I think most of us do realize that our software also might not work as intended. Even simple projects can have bugs and holes that we’ll find when edge cases are introduced or the software is used in a way we didn’t expect. At least I hope it’s just unanticipated, edge cases and not general cases for most of us. If an application doesn’t work for the cases we’ve designed it for, then we need to work on our coding skills.

We know that building software is hard. We know that outside of a narrow domain for which we’ve often designed our software, it might not work as intended. Most of us expect to find bugs or problems in our software, and are mentally prepare to patch and enhance our work as needed. It’s almost inevitable, and even occurs when you design your own software, to do that one thing you need done. You’ll still maintain (meaning patch or enhance) the software over time.

I hope that’s not too gloomy a view of software.

Steve Jones

Video and Audio versions

Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.