dougv.com « Doug Vanderweide

A common need in the ASP.NET world is how to back up a remote SQL Server database, usually provided by someone else. Sometimes, you want to occasionally run a backup as an extra layer of redundancy; other times, you are changing hosts or want to be ready to do so.

How you back up a remote SQL Server database depends largely, if not entirely, on the tools your Web host is willing to give you.

Most Web service providers will give you some implementation of a BACKUP Transact-SQL query; the resulting .bak file is then either put into a directory on your Web server, or you’re given a download link. And generally speaking, that .bak file is enough to create a fresh version of your database, either at the same host or someplace else.

But not always. You generally can’t be sure of the integrity of a .bak file run by a Web service provider; you also may find that, due to the way that WSP’s servers are configured, the backup file it creates won’t work elsewhere, or are problematic to use. I’ve had bad luck using .bak files to replicate databases between Web service providers.

Another option is to simply download the remote database’s MDF file. I like this approach best because as a rule, if you have the relevant MDF file and the same version of SQL Server, you can simply attach the MDF file to a new SQL Server instance, and it’s like the database was there all along.

There are two more options available — again, depending on how your Web service provider allows you to connect to the remote database — and I’ll blog on both.

Today, I’ll discuss using SQL Server Management Studio Express, and its built-in scripting tools, to dump your remote database to SQL command files. Next time, I’ll write an ASP.NET script that will back up our database to SQL files.

Continue reading: Backing Up Your SQL Server Database To SQL Files With Management Studio Express »

As I was saying … today’s comic from xkcd:

It’s a trial for me to listen to people complain about privacy on Facebook or anonymity on the Web.

Don’t get me wrong; you aren’t going to find a bigger defender of anonymous speech than me. The same way a secret ballot preserves the integrity of the plebiscite, anonymous political speech protects republicanism.

But there’s a difference between standing up for the right of someone to publish an anonymous blog and listening to people carp about whether some stranger can see pictures of his kids.

In the case of the former, the author wants to be heard, but to protect himself from the repercussions of speaking. That’s a tradition as old as politics itself, albeit that in time, anyone who makes an impact with anonymous speech is exposed.

In the case of the average Joe bitching about his boss via a tweet, there’s a far simpler point to be made: If you put it on the Internet, it’s not private. Period.

When we waste time debating whether it’s right for some potential employer to use a five-year-old drunken tweet against you, we don’t focus on the real things people should be doing to protect their Internet identities. For example, using strong passwords.

I’ll bet a dollar to doughnuts that the average person who worries about Facebook privacy is using his dog’s name as his Facebook password. And not only that, but using that same password for every Internet site he visits, including Amazon.com, online banking, travel sites, etc., etc. And not only that, but has been using the same password for years.

I’m willing to make that bet because that described my password strategy up to about a week ago. Until I discovered, and started using, LastPass.

Continue reading: LastPass: A Great Way To Protect Your Actual Internet Privacy »

The New York Times’ Bits blog has a post today in which chief Facebook lobbyist Elliot Schrage answers reader questions.

For a lawyer — especially a lawyer facing a Bonfire of the Vanities-worthy media frenzy, a meddling Congress, watchdog groups barking at his door and an inchoate Intifada by his longest-standing and most important partner — Schrage was pretty forthcoming; most lobbyist / marketers would equivocate their way out of a similar mess.

Actually, if you read the Times blog post closely enough, Schrage effectively admits it’s that sort of behavior that has put Facebook in hot water:

“Our desire to innovate and create new opportunities for people to share sometimes conflicts with our goal to create an easy and accessible user experience,” he wrote in the introduction. “It takes forums like this to get better ideas and insights about your needs.”

Which is the purpose behind this post. I’d like to put, in layman’s terms, Schrage’s answers to each of the questions posed, and either provide the answer I wish he had given — that is, an answer that is the plain truth about why Facebook does what it does — or expand on what he said.

Q: “Why can’t you leave well enough alone? Why do I have to do a weekly ritual of checking to see what new holes you’ve slashed into the Facebook Security Blanket, so that I have to go and hide or delete yet more stuff? Are Facebook customers really pounding on your door screaming that they want more categories of their personal data to be available to marketers every few months?”

Schrage: We are clearly upsetting people by making changes as often as we do. No personally identifiable information is shared with advertisers.

Me: Social media is young. What works and what is profitable changes quickly; what fit into the way Facebook did things, even just a few months ago, may be cutting off opportunities to make money or head off challenges from other social media providers today. That’s why things change so much: To protect and grow Facebook’s market share.

If you’re going to complain about Web advertising based on browsing habits, you probably should have stopped using the Web back in 1996. And if you’ve ever used a coupon, promo code, frequent buyer card or gift card, I’d like to kick you in the butt as I explain what, exactly, constitutes behavior-based marketing.

Continue reading: The Answers I Wish Facebook Had Given To User Questions »

Crowdsourcing is all the rage these days, and even if you’re not managing a social media Web site, sometimes it’s helpful to accept content from end users.

For example, one of my clients has a community calendar on its Web site. Since the inception of the calendar, staff time had been devoted to retyping e-mailed and snail-mailed items into that calendar’s back end.

That was almost entirely wasted time, which my client rightfully wanted applied to something more profitable. My client wanted to allow staff to approve, edit or delete calendar submissions before they appeared on the site, but asked me to shift the burden of actually adding items directly onto the shoulders of site visitors.

Thanks to ASP.NET’s built-in membership system, we can easily provide a simple system for allowing end users to provide content. Not only that, but thanks to the role-based permissions incorporated into membership, we can even presort content to specific sections of the site, based on who is submitting it; grant specific users or user groups the ability to bypass an approval process; throttle contribution allowances; basically, any permission or restriction you might want to use.

(Aside: We can similarly implement a model like this in PHP, but it does not have a built-in membership provider. I may, at some later date, describe building a PHP membership provider that is similar to the ASP.NET model, at least in terms of practical use, if not mechanically similar.)

I am going to make a simple cancellations notification system as my demo.

After all, everyone wants to know if school is closed, or whether the play is still on in spite of the weather. Because canceling school, play, etc. generally comes down to a single person’s decision — or, at most, a few people — we can easily provide a system to log in, select a few options or enter a bit of text, and save everyone the time and grief such notifications otherwise take.

The specific features I will demo, in this and upcoming blog entries, will be:

• an administrative interface to add, edit and delete memberships;
• another administrative interface to add, edit or delete membership roles (i.e., membership groups), and to assign members to those groups, as well as to assign users to specific schools, organizations, etc.;
• an administrative interface to approve, edit or delete cancellation notices;
• a private form to allow membership to post cancellations for the schools, organizations, etc. with which they have been associated;
• a public view of cancellations that have been approved for viewing.

Continue reading: An ASP.NET System To Allow Site Members To Contribute Content, Part 1: Overview »