« May 2006 | Main | July 2006 »

June 20, 2006

Deciding between SQL Express, JET and SQL Everywhere

This is one of the most hotly debated topics around so expect quite a few opinions. My TechEd talk (which might be posted online on the Microsoft site sometime in the near future) discusses where SQL Server Express Edition fits in relation to JET/Access and the newest DBMS system SQL Server Everywhere (SQL Ev). Yes, there are a lot of choices and each has its place.

 

A number of factors should be considered when you're trying to decide which approach to take. These include (but are not limited to): 

·         How do you intend to deploy the database? Is it to be included with the other files deployed with the application? The new One-touch deployment schemes in Visual Studio can make this easy (or a nightmare). SQL Ev is especially easy to pass around in email or by any means.

·         Do you need to deploy it at all? Can it simply be accessed over the local area network? In this case it’s best to choose a service-oriented approach like SQL Server Express or one of the “paid” SKUs.

·         When you use SQL Server you either need to run setup on the target system (as an administrator) or access it as a network service. SQL Ev does not have this limitation if you imbed its DLLs in your application.

·         Is the system connected to a network? Is this connection likely to be broken as when deploying to a smart phone, PDA or a wireless network? In this case, hard-connection strategies simply aren’t reliable enough so you’ll want to consider using a replication-based architecture.

·         Do you plan to access the database over the web? In this case, you’ll need SQL Express visible to the IIS server—SQL Ev is not suitable for this job (and is intentionally disabled in this scenario). Generally, we approach this problem by writing an ASP application or a Web Service that accesses data to be passed back as HTML or XML (or if you’re clever, using remoting).

·         Do you or can you create the database on the fly? In some cases it’s just as easy to create the database on the fly—this can be as simple as 1 line of code (in SQL Ev) or take an entire routine to accomplish.

·         How much data do you expect to manage? If it’s over 2GB, you can’t use JET/Access and if it’s over 4GB you’ll need a paid SQL Server SKU or some third-party DBMS.

·         How many users do you expect to share the database? There are lots of applications that simply need a local data store—with a single user (the application). SQL Ev is perfect for this. It’s light, fast and does not run as a service so it has no residual overhead. If you expect to support dozens of users, you’ll do fine with SQL Server Express (as a shared service).

·         Does the application run on a workstation along with other applications? In this case the application needs to be “well-behaved” and not consume every bit of RAM in sight. SQL Ev has the smallest footprint of all (about 1.7mb). SQL Server consumes a lot more RAM but does yield it when requested. Because SQL Server runs as a service, it constantly consumes CPU time—even when not servicing queries. This means you might want to add code to stop it when it’s no longer needed. Note that when you use the “User Instance” approach with SQL Server Express, it actually is running two instances of SQL Server.

·         Does you application need to scale up to or also connect to another DBMS? In this case you need to consider SQL Express as it supports all of the same programming interfaces as the paid SKUs. This means when it comes time to upscale, you can simply attach the database to the larger SQL Server. SQL Ev uses a simple subset of the basic relational database constructs—for example, it does not support Views, triggers or stored procedures.

·         Is the DBMS supported or just obsolete? Microsoft is trying to move developers away from JET/Access databases (not Access the product) so I can’t recommend it for any business applications. (Okay, there are a dozen more reasons why I don’t support JET but we don’t need to go there again).

·         Is the DBMS secure (enough) for your requirements? Security should probably be at the top of this list. Each DBMS implements (or attempts to implement) some form of security. Only SQL Ev can be totally encrypted which means you can (relatively) safely pass its database file around without worrying that it contains malicious code—it does not have the ability to contain executable code of any kind). SQL Express’ security model really hinges around “physical” security. That is, it depends on the system that hosts the DBMS to be kept secure. This means you’ll want to encrypt the SSAN and credit-card data columns as well as any other sensitive information kept in the database.

I just finished my new book (expected to ship this summer) that details these issues (and many more). Keep an eye on www.hitchhikerguides.net for details.


Posted by William Vaughn at 10:03 AM | | Comments (3)

June 19, 2006

Getting and Staying Connected (Updated October 2007)

In the newsgroups and in my conference sessions, there still seem to be a lot of questions on getting and staying connected to SQL Server--especially with SQL Server 2005 Express Edition. Perhaps the checklist shown below can help. This content is extracted from Chapter 9 in my book "Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)" available in bookstores and online all over the world.

There is also a good source of low-level detail on connecting here in this MSDN article.

If you're having problems accessing SQL Server on a local system using SSPI (trusted) connections, check out this blog entry.
style='mso-spacerun:yes'>  This whitepaper assumes that you’ve already
begun to implement an application and can’t seem to get connected (or stay
connected).

If you still find that this information is not enough to get you connected to your SQL Server database engine or you need one-on-one support, feel free to contact me for a personal mentoring session or attend one of my conference sessions that focuses on your specific needs. I have also updated my whitepaper “Managing and Monitoring .NET Connection Pools” which discusses a number of pool-related issues as well as architectural design issues that can help eliminate a lot of needless overhead while connecting.

Understanding the Issues

Yes, connecting can be a ... well, problematic. ASP apps also pose additional issues but anyone working with IIS and remote server instances can tell you the same. Consider that SQL Server's default behavior often makes it invisible to the outside world—even your own system in some cases. SQL Server can be accessed via DBLibrary, ODBC, OLE DB or native .NET data providers but I recommend that you use the .NET SqlClient namespace for best performance and most reliable connections—at least from .NET Framework applications. For COM-based ADO (what I call ADO Classic) I recommend using the SNAC OLE DB (COM) provider which is designed specifically to enable SQL Server 2005 functionality. Each SQL Server data access interface requires a specially formatted ConnectString to identify the system hosting the SQL Server service and usually the name of the SQL Server instance. It also specifies the security protocol to use and usually the default database.

Configuring the Server and Choosing a Protocol

Anytime you want to access SQL Server you’ll do it over the network (typically using TCP/IP protocol) if your SQL Server instance is not hosted locally. If you are accessing a local instance (as is typically done with SQL Server Express Edition), it’s best to use ConnectionString keywords that reference the (local) or “.” system. This tells ADO.NET to use the Shared Memory provider which is fastest (and simplest) of all providers.

 When traversing the network to get to your chosen SQL Server host and instance, keep in mind the protocols, ports and the firewalls that protect them must all be correctly activated and configured. It’s best to use the SQL Server Surface Area Configuration tool and SQL Server Configuration Manager to inspect and configure the appropriate protocols, ports and services—before you try to connect. Remember that by default SQL Server does not always expose itself to the network. If you’re having trouble connecting, make sure you visit the aforementioned tools to enable visibility.

Unlike SQL Server 2000, you’ll also need to start the SQL Server Browser service for all SQL Server 2005 editions if you want the SQL Server service exposed on the LAN. This additional layer of security ensures that unless you specifically ask for it, the existence of your SQL Server instance(s) will not be broadcast on the network for all to see.

Before you connect, SQL Server must be pre-programmed to accept the connection with the given security credentials and must have granted the specified login ID rights to the chosen database. In the case of SQL Express installed using the User Instance=True keyword, the current Windows User is assumed to have system administrator (SA) rights but you must specify “Integrated Security=SSPI” for this to work. This is a complex subject. If you plan to take this route, I suggest reading Chapter 9 of the aforementioned book.

In a Nutshell

Let’s summarize: In order to connect to SQL Server several factors must be in place. If something goes wrong, you might find that the exception handlers used by the SQL Server providers lack a great deal of granularity. All too often they return a message:

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (Microsoft SQL Server, Error: -1)

This generic one-size-fits-all error message is returned whether or not you are attempting a “remote” connection. No, don’t bother clicking on the help icon—there is no additional help provided by Microsoft. However, in this case note that the hint at the bottom tells us that the server/instance could not be found. Remember that when you use a name to refer to a server on the LAN the DNS server must resolve this name and the server itself must be configured to expose it. If the DNS service is not programmed correctly, it might not be able to see your SQL Server Instance. Unfortunately, the reason you get this message might have nothing to do with remote connections configuration.

Other impediments to connecting include XP and other firewalls, security configurations, improperly enabled ports, incorrectly installed server instances, missing databases or user accounts and in the case of IIS/ASP applications incorrectly configured accounts on the server to map the IIS anonymous accounts.

The Connection Checklist

The following checklist should help your code get (and stay connected) to any instance of SQL Server.

Your application must identify the machine name and the instance of the target SQL Server. This means you’ll need to reference the machine name and the instance name unless you have installed SQL Server as the “default” SQL Server (the only option pre-SQL Server 2000). The syntax is “SERVER=<machine name>\<instance name>”. If you didn’t specify an instance name, the default SQL Server instance is referenced by the server name as in “SERVER=<machine name>”.

1)      To identify the local machine name, you can use “.” or “(local)” or in VS 2005 (2.0 Framework) you can use My.Computer.Name. You can also define an alias to address a specific machine and instance and use this alias in the Server= element in the connection string. The term “localhost” refers to the local TCP/IP address and is used to access the local IIS server, not the local SQL Server.

2)      When connecting to an instance of SQL Server directly via an IP address (which raises a number of scary security issues), see the addendum at the bottom of this checklist.

3)      The Directory Name Service (DNS) in your domain must be able to identify the named machine (it must resolve to a valid IP address). If the DNS is not working, the server can't be found. In this case it might be necessary to alter the “hosts” file (Windows\system32\drivers\etc) to map a specific machine name to an IP address to circumvent this issue. DNS accessibility can be a function of how the NIC is configured or the availability (state) of the domain controller. Check with your system admin about DNS issues.

4)      SQL Server 2005 no longer broadcasts availably of its instances on the LAN—that’s now done by the SQL Server Browser service. If you need to access an instance of SQL Server on another system, the SQL Browser service must be running on the host machine.

5)      The targeted SQL Server instance service must be running on the specified machine (not stopped or paused or in recovery). Remember that SQL Server can be configured in single-user or paused mode or the service might be stopped for some reason. These states don't permit external connections. You can check the status of the service using the services.msc MMC snapin or via code (2.0 Framework). It might be a good idea to check with the SQL Server DBA before arbitrarily restarting the service.

6)      If (and only if) you're using SQL Server authentication, the server instance must be configured for mixed mode security. By, default SQL Server is not configured to support SQL Server authentication (what’s called “mixed-mode” security).

7)      If you’re using SSPI authentication (Trusted Connection=True or Integrated Security=True (or SSPI)), the Windows account you’re using (or impersonating) must have an account on the server one way or another. This means there must be a SQL Server login that grants sufficient rights to the user’s group. By default, Windows users in the Administrators group are granted access to all objects but the DBA might (and usually does) restrict those rights. In any case, the login account specified in the ConnectionString or inferred (with Integrated Security=SSPI) must exist and be granted rights to the initial catalog (the default database).

8)      In the ASP case, IIS opens the connection as ASPNET (pre-Windows 2003) or IUSR_<machine> so this login must be granted rights. Yes, you can try to impersonate a Windows user using an ASP application, but this is complex to setup and keep working. Other complicating factors here include running the SQL Server on a different system—other than the IIS system. ASP applications might have to run under a trusted domain account.

9)      If the SQL Server instance is hosted on another machine, depending on the protocol you choose (or is chosen for you), you must punch a hole or two in the client firewall. This means getting into the Windows firewall program if it’s enabled. If the server is on the local system, it's best to bypass the network providers and use the shared memory provider.

10)   You must also make sure the protocols you need are enabled on the server—they are off by default. The best way to manage the services is using the SQL Server Surface Area Configuration tool and the SQL Server Configuration Manager. Generally, you only need the TCP/IP protocol.

11)   The server itself must have available connections—this is not a given. Check the server configuration to ensure that the license restriction or the DBA-imposed restriction on accounts has not been exceeded.

12)   The connection pool must also have available space. In this case, your connections will be accepted at first but once the pool is full additional connections will fail with a timeout exception. No, increasing the size of the connection pool won’t help any more than putting a band-aid on a leaking boat’s hull. Managing and monitoring the connection pool is discussed in great detail in the book. It’s summarized in this whitepaper.

13)   If you’re getting timeout exceptions on the first attempt to connect, it’s unlikely that the connection pool is an issue but available resources, LAN latency and other hardware configuration/performance issues could be playing a role. If timeout exceptions occur after that, check the connection pool (as described in the aforementioned whitepaper. A full pool is an indication that you’re not releasing connections in time. Typically, this means you aren’t closing connections or you’re pushing the server too hard.

14)   While the new ADO.NET 2.0 exception handlers are better than the old handlers, they often return a generic message that doesn't really help (as discussed above). They will tell you, however if the provider has found the server or not. Once the server is accessed, the next layer of protection is rights. That is, does the set of credentials specified have access rights to the initial catalog (default database) in question?

15)   The ConnectionString parser in ADO.NET 2.0 is better than ever. It’s more tolerant of additional spaces and such and will simply report an exception if the syntax is incorrect. That said, remember that the ConnectionString is used to test for existing connections in the connection pool. It can’t vary from connection-to-connection without creating a new pool. Connection pooling issues are not a concern for Windows forms applications (smart clients), but are a vital issue for ASP and Web Service applications.

16)   For Windows 2000 and XP IIS logs on using “ASPNET” account credentials. For Windows 2003, IIS uses “INetworkService” by default. Some folks think that impersonating another account for XP and Windows 2000 is not that hard. They say there are at least three ways to do it:

a)      In web.config

b)      Change the anonymous account on the IIS server and in web.config set:

c)       For Windows 2003 you must setup a new application pool with the new account as its identity. (Thanks to Patrik Löwendahl [C# MVP] for this contribution.)

17)   When connecting to a SQL Server instance connected via IP address: While 1433 is the official Internet Assigned Number Authority (IANA) socket number for SQL Server, you should still determine the port being exposed by the targeted server instance—each instance can be addressed by its own TCP port. The SQL Server Configuration Manager exposes the IP address of the TCP port if it has been assigned.

a)      If Dynamic Ports are enabled, then you need to determine that port. See KBs 269882, 823938 and 287932 for more details.

b)      Using the same tool, make sure the TCP/IP protocol is enabled.

c)       Using your Firewall administration tool on the client and the server, make sure this port is not blocked. It will be blocked by default.

d)      Make sure your connection string uses “Network=dbmssocn;” as the protocol.

e)      It might be easier to simply add an alias to the Host file located at “C:\WINDOWS\system32\drivers\etc”.

I hope this helps.

Posted by William Vaughn at 12:41 PM | | Comments (2)

June 16, 2006

Connect-Query-Disconnect in Client/Server

In response to a newsgroup question where an ASP developer (who had seen the light) wanted to know if it was still necessary to immediately close connections or if it was okay to keep them open.
________________________________
Unless your server is supporting many hundreds of users or you're under a licensing restriction, you can easily get away with creating and holding connections--lots of them. The disadvantage to this approach is that it ties up some resources on the server to maintain your connection state--but so does the connection pool approach. The advantage is that you can build and maintain state on the server. This state can consist of server-side temp tables, specific SET configurations and server-side cursors. These can't be leveraged in an ASP environment (which is probably why they were not brought forward with ADO.NET). For example, you can build a #temp table that contains user-specific rowsets, index it and use it in subsequent JOIN statements to (dramatically) improve performance. In the past (before connection pooling) we used this approach quite effecitvely and simply timed out the connections after N idle minutes.

Posted by William Vaughn at 01:41 PM | | Comments (2)

June 14, 2006

SQL Server Express--Deploying the database

Steve Lasker came by and recommended this blog article written by Rob Walters. It includes a number of good tips you'll need when building and deploying SQL Server Databases on client application platforms.

Posted by William Vaughn at 06:15 AM | | Comments (0)

June 12, 2006

TechEd 2006 Boston--The Keynote

I made two mistakes last night. First, I didn’t stand in line to get into the TechEd 2006 (Boston) keynote early enough to get a seat near the aisle. The second mistake was attending in the first place. Earlier in the day we had an MVP meeting where we heard from MVPs that Microsoft’s focus seemed to be toward the “Enterprise” and away from smaller companies. This message was pretty clear in the keynote address. Virtually all of the features demonstrated and “promised” (except Avalon) were clearly for the largest of companies. What I did hear (that was worthwhile) was the new technology that promises to encrypt the contents of a laptop’s hard drive so a nefarious thief’s only option is to reformat the drive or toss it in the East river. Unfortunately, this technology comes far too late for the veterans and active-duty military whose data was lost. Keep reading...


Another “interesting” demo illustrated refactoring data in the Team edition—they showed how to change the name of a column in a database and propagate this change to all T SQL (not CLR) stored procedures, Views and (possibly) indexes. This operation was done on a live database (hopefully pre-release) but it took quite awhile to complete—flashing and repainting for way too long. And what about the other external dependencies? What about the other applications being developed or deployed that reference this table’s column by name? Did the dependencies tree show how this change would impact those applications? What about the TableAdapter and DataSet objects referencing this table column by name? What if there were CLR executables bound to this column? While this feature might be interesting in specific cases and make a flashy demo, leaving these questions unanswered can lead customers to think that the Team Systems folks at Microsoft don’t really understand how development shops (especially smaller ones) really work.
I think there are a wealth of interesting and useful features in Visual Studio that could have been shown—focusing on a feature and a product that only appeals to the largest enterprise customers means that Microsoft really does not know from whence its revenue comes...
And what’s with the blonde? Having an actress (albeit popular) come out on stage and try to show how dumb someone can be did not make me feel that comfortable—the response she got from the crowd should have been a clue that this was perhaps not particularly on target. We need to encourage women in this industry—not make them look incompetent.
Microsoft missed a golden opportunity to show their developer base that they really understand them and their needs. These customers are mostly ordinary developers from a wide breadth of skill levels and abilities. While some might work for an “enterprise” organization, these folks often work in smaller, more focused IT departments with less grandiose requirements.
I won’t get into the way the busses were handled. That I’m sure will be the fodder for other blogs.
They’re having me give a chalk-talk tomorrow morning. Too bad it’s not advertised anywhere. None of the chalk talks are in the schedule or where someone could find them. The sessions are in the schedule, but the name of the speaker is not… I guess we’re supposed to hunt up people to attend on our own.

Posted by William Vaughn at 07:53 AM | | Comments (1)

June 03, 2006

EBooks--Profit for Pirates?

It’s become pretty clear that the technical book-writing business is not worth the time and effort—not to mention the years of time that I could have been contributing elsewhere. But is there a better way? This article explores the mechanics of writing technical books and the alternatives.

Drawing a Portrait When the Subject Won't Sit Still
The problem with writing about Microsoft technology is that it’s constantly in flux. It’s like trying to paint a picture of a new airplane as it comes in to land. The beta versions are akin to rumors about what the plane is supposed to look like—what the aircraft designers intended, promised or promoted in the years before it made its first flight. As the plane comes in you can start sketching out the plane and as it taxies in you can really add in the detail. With technical books, every bit of that detail is what your readers want. Sure, they want to hear about the new features, but Microsoft provides lots of information about these. Readers really want to know how well the new version meets the hype and their specific needs. It’s only when one can get onboard and get a close look at what’s been done behind the pull-up plates that a writer can figure out if they’ve done a good job of meeting their promises. Unfortunately, given a 12-18 month ship schedule, about the time one’s finished with the book, the plane takes off and its replacement is about ready for alpha testing back at the plant.
Book Publishing is Unchanged Since Gutenberg
The other problem with paper book publishing is that the publisher can’t print the book a chapter at-a-time. They want the whole manuscript bundled together in one or more volumes of 700-1000 pages and they want them the second the plane lands—when the product hits RTM. This is impossible. Given that we don’t really know what a product will really be like until we test the final version it’s impossible to meet that deadline. Understand that while Microsoft has started giving out Community Technical Previews (CTPs), these versions are often trial balloons to see how well a feature is received and to see if it works with other features. If the critics pan it or it simply doesn’t work, Microsoft either fixes it, drops it or delays it until the next release—which can only 20 or so months away from the early CTPs. I can’t write books on vaporware—on features that they hope to be present in the final product. It’s just a waste of time.
Given this reality, authors have to hide the new chapters for over a year to prevent their innovative ideas and insightful examples from leaking into other authors’ books and articles (which frankly pay much better). At this point I have over 700 pages of content waiting for Addison Wesley to edit and get published. They hope to have it done before the next version ships. I hope so too.
Perhaps, Just Perhaps EBooks Are an Answer
I think a solution to this problem is EBooks. The problem here is that those who would rather steal the content and profit from it themselves are sucking the life out of the business. Try as we will to harden the content, there are those that still find ways to reproduce and even translate the content in China, India and elsewhere. The publishers are often powerless to do anything about these thieves who don’t mind stealing from Americans or others. Their governments are often in on the profits and turn a blind eye to these activities. I interviewed a number of Chinese that deny it even happens—they say it’s those people in Hong Kong. They forget that they are Chinese too. Whether or not it’s done in Hong Kong or New Delhi or Cleveland it’s still theft.
Regardless, I think I’m going to try to publish updates to my new book as EBooks. We have not decided on a “publisher” as we can actually do this ourselves and get a far higher rate of return. Yes, there are some expenses involved—I would need a high-speed uplink installed, buy a license for some IP-protection software and manage the incoming payments and customer support calls. But these all seem doable. Addison Wesley and SQL Server magazine have both promised to give us quotes on EBook publishing—they have yet to do so. It’s a new business for most folks so it’s important that we try to get it right the first time.
If you have an EBook publishing experience, let me know. I would love to hear about what works, what doesn’t and what you have learned. Perhaps I’ll write an EBook on the subject… maybe not.

Posted by William Vaughn at 10:46 AM | | Comments (1)

June 02, 2006

TechEd Boston--My Chalktalk on the ReportViewer

So, they tell me that I'm doing a chalk-talk on the new ReportViewer control in Visual Studio. That's cool as it's one of the most interesting additions to the Visual Studio tools suite. The question is, how the heck and I going to do an hour-long presentation without a demo, or a projector to show it with? I'm thinking about bringing hand-puppets. Check the schedule for the exact times but I asked for Tuesday or Wednesday morning sometime. I'll probably get 0-dawn 30. I expect that most folks will want to know how much of the work they've invested in the Reporting Services RDL-based reports can be leveraged with the ReportViewer.

I wrote quite abit about that issue in my new (as yet unpublished) book "Hitchhiker's Guide to Visual Studio and SQL Server". The ReportViewer chapter is over 70 pages IIRC and takes the reader through the mechanisms used to
transmogrify RDL into RDLC. Frankly, that's the easy part. The problem is the RS UI handles a whole series of issues including prompting for parameters, running pick-list population queries, populating the pick lists, setting
defaults and valid options and a lot more. All of these tasks have to be picked up by the Windows (or Web) application unless you simply want to use the ReportViewer to address the Reporting Services engine and pick a report to view. We'll certainly have time to discuss those issues and understand where SQL Server Express (Advanced Services Edition) fits into the picture.
Questions? Ask or see me at TechEd.

Posted by William Vaughn at 04:04 PM | | Comments (0)

June 01, 2006

So, Where's the Book?

I get that a lot. Most folks know that I've been holed up working on the latest Hitchhiker's Guide. This (7th) edition was not a minor update like several of the earlier versions--I started from a blank slate over a year and a half ago. Sure, I couldn't really start building test and example applications until Whidbey shipped. I think it's a phenomenal waste of time to write "beta" books that have the shelf life of a roman candle on the 4th of July.

This time I wanted to write a book that would last beyond the current version of Visual Basic, Visual Studio and SQL Server. That’s one reason I pulled the “2005” from the title. The new book takes a big step back and for the first time includes chapters to help those without 10 years of experience in data access get a foothold on the technology before diving into subjects like, optimizing queries, rights management, CLR executables, sophisticated connection management or business rule schemes. For example, the new book has a chapter that answers the question "How Does SQL Server Work?" I included this content because of the questions we get from the newsgroups and my sessions that belie a fundamental understanding of SQL Server’s inner-workings. I show how a query is processed, compiled and cached and how SQL injection can give your simple application a passkey to the entire system. I talk about performance, security and best practices in terms anyone can understand.

I recognize that most of the developers I meet are specialists. They understand hotel management, healthcare, time-and-billing, insurance, federal accounts, oil-field management or process-control issues but they don’t necessarily know how to store data and retrieve it efficiently. They often don’t understand tiers or strongly typed data structures and sometimes could care less. In some shops “efficiency” means fewer lines of code to write and support instead of being able to fetch data faster. In other cases, techniques to blast millions of rows of data from place to place is also important—given my penchant for “really-big” data, I try to show a number of patterns that avoid building bulk-copy replacements.

Security is also a big issue and one that (or so it seems) not everyone understands. It’s critically important for everyone assigned the responsibility to handle our data to understand how to protect that data from those that would compromise it. The solution to this problem is more than just encrypting files and columns, login accounts and credentials. Since Visual Studio does little to help set and manage database rights, the book discusses how to use the tools in SQL Server Management Studio to deal with this responsibility. There really isn’t a single chapter on security—the concepts are woven into the fabric of each chapter.

I can’t tell you how frustrated I am at this point in time—I’ve been telling people that I’m suffering from post librum depression. Now that the book is pretty much written I really want to show it to everyone but I can’t. At this point I’m still waiting for the reviews and edits to come back. They tell me the book is on the fast track—I certainly hope so. Perhaps we’ll see it before the fall conferences.

As I still want to keep writing, it’s clear that technical writers are going to have to come up with other ways to get our content into the hands of the public. I think EBooks might (just might) be a good way to go. This approach really hinges on how secure we can make the content. Even though I only sold one copy in Hong Kong, my 3rd edition was very popular in China. I really think that some tough-to-crack technique needs to be found to protect our intellectual property from those that would steal it.

 

Posted by William Vaughn at 01:54 PM | | Comments (0)