So normal output redirection is handled with just the > or >> operators (depending on whether you want to overwrite or append the target file), like so:

dir >> myfile.txt

The operator outputs the stdout stream by default. But it can be modified to output the stderr stream by just specifying that stream with the operator. Remember, stderr is stream 2. So, you would do like so:

dir 2>> myfile.txt

This would write only the error output to the file.

At first glance, you'd conclude the process would work much the same way: Loop through the individual directories in the large repository, create smaller repositories for each one, then dump and import the contents of each directory into its small repository.

The tricky part is that the Subversion dump command dumps everything in the repository, by revision. In order to pull just a single directory, you must filter a complete dump with the "svndumpfilter" command. This blog post by AllMyBrain.com basically explains how to accomplish this in Linux. I usually have to work on a Windows box on the job, so I wrote up a script to accomplish this in a Windows batch script.

The strategy is the same as the Linux script, though. We're going to use "svnadmin dump" the large repository, then use "svndumpfilter" to filter by just the directory we want, then "svnadmin load" the results into the newly created repository. All of this can be combined into a single statement via piping:

This will make a little more sense when we look at the full script. Let's just put it out there and then go through it.

First, we're setting our paths. "SmallRepoPath" will be the directory holding all of the small repositories we'll be creating. "PathToRepo" and "UNCToRepo" point to the big repository as DOS and UNC paths, respectively. "PathToChkout" points to a Subversion checkout of the large repository.

First, we check out the large repository with the "svn co" command. We do this just so that we can call the "dir /A:D /B" command, which says, "List just the directories in the checkout directory." We use that output to loop through each directory in the large repository.

Then, for each directory in the large repository, we create a corresponding small repository, then do our dump/filter/load combo. Again, we're dumping the contents of the large repository, using "svndumpfilter" to filter by directory, then loading that filtered dump into the new small repository.

Finally, we just do some cleanup by removing our temp files and the checkout directory.

There are a few caveats with this code.

First, it will import all of the large repository's revisions into the smaller repository. There are svndumpfilter arguments to prevent this, such as --drop-empty-revs and --renumber-revs, but I found the Windows Subversion binaries to be problematic with these arguments. The end result is that you have more revision numbers than needed, but only the relevant data is actually imported into the repository, and viewing logs on just the imported directory will still obviously show revision logs related to that directory, so there's really little harm done.

Second, the dump/filter/load action doesn't always work on a directory that has been moved (copied/deleted) from another location within the large repository. What's worse, it won't fail, it just won't load any data into the small repository. To address this, use the --revision argument on the "svnadmin dump" command to do a dump starting at a revision after the move took place. Doing so will give the "svndumpfilter" command something it can work with.

This process is certainly more complicated to explain, but ultimately there's not that much more going on. Hopefully this explanation is helpful to you.

The insanity had to stop! A handful of databases like this would put us over the top on that particular server's hard drive storage.

The SQL Server GUI for shrinking the database rendered no effect, and even using the DBCC SHRINKFILE command was not working.

The key, as explained by Pinal Dave, is to run the SHRINKFILE command twice, with an explicit backup log truncation in between both runs. This code here will get you up and running:

This freed up dozens of gigabytes on our server.

That said, there are advantages to having one single repository. No big deal, that can be done after the fact with code.

Here is some Windows code to combine all the repositories in a directory into a single big repository:

There's really not much happening here; the process is simple. First, we create the new "big" repository with the svnadmin create statement. Second, we loop through the directory, processing each Subversion repository in the directory with a three-step process: (a) Dump the repository with the svnadmin dump statement into a temporary *.dmp file. (b) Explicitly add a new directory in the "big" repository for the current repository we're processing, with the svn mkdir statement. (c) Import the dump into the "big" repository with the svnadmin load statement. Really, the rest of the code is just looping, commenting, or cleanup code.

What have we produced? As you might expect, we now have one big repository that has all of the files and commits that were in all of the smaller repositories. The big repository will maintain its own revision numbering, so the revision numbers in your smaller repositories will not match the big repository's revision numbering, although the original commit dates will be preserved. This can be really handy for searching or similar actions that you might do from a more global perspective.

However, this approach is not without its caveats. During the import process, one entire repository is imported at a time. All of a particular repository's revisions will be "grouped" together in the big repository. As a result, revision numbers in the big repository will change every time you recreate it, if there was any new activity in the repositories it contains. For instance, revision #1050 in the big repository may parallel revision #500 in Repository X, but if a commit was added to a repository that is imported before it and the big repository is recreated, that revision would now be #1051. Additionally, although all history and dates are preserved in the revisions, the big repository has commits that are not in chronological order since the import was processed by repository. This inconsistent date/commit ordering can be confusing to some repository reporting tools and may actually render those tools useless to you when they are reporting by date.

Filtering by revision. Note that my svnadmin dump statement includes the -r argument, which specifies the beginning and ending revisions to dump. By default, I'm using "0:HEAD", which basically means "dump every revision", or "dump from the first revision to the HEAD, or latest, revision". Changing the beginning and ending revisions can be useful, especially when used with dates instead of actual revision numbers. For instance, you could change the value to {2007-01-01}:{2007-12-31} to only dump revisions that were committed in 2007.

Combining all of your smaller repositories into one big repository after the fact isn't a perfect solution, but it can be handy, and it's really easy to do when you have a script like this ready to run.

Well, you can find all of your views by querying the sysobjects table, and you can retrieve the SQL behind the views by querying the syscomments table. Something like this works well:

This will retrieve the SQL code and names of all the views in the current database. This simple query is the heart of the solution. But I would like to retrieve this information for all of the databases.

Well, it's easy enough to get a list of all the databases. The sysdatabases table in the master database has that list. You can query that table, perhaps filtering out some of the system or sample databases included with SQL Server:

Now just combine this information. To accomplish this, we'll build a stored procedure that will create a temporary table, loop through the databases and query each one for its views, insert the view information into the temporary table, and return the temporary table.

Something like this will do the trick:

Now just execute the stored procedure and review its output.

This portion of the solution just retrieves the data. After writing this, I developed a really short and simple ColdFusion application that would output the database name, view name, and SQL to a table, and used some simple JavaScript to make it easier to search and filter the views. The client-side methods used to view and work with the data are obviously up to you.

That said, please note that the drivers that come with CF8 do not support Access 2007. This is mentioned in the ColdFusion 8 Release Notes under #69495. The solution is nicely described right in the release notes. Download and install the Data Connectivity Components for Office 2007, set up a Windows ODBC connection, and use ColdFusion's ODBC socket driver to connect to the Windows ODBC connection. A bit irritating that all of this has to be done, but like I said at the outset, these irritants are the price you pay, among other things, when using Access databases.

Another point to note! You thought you were done, but no, Microsoft has more joy in store for some of us.  The Office 2007 drivers do not support Windows 2000. So if your server is still sitting on a Windows 2000 installation, the final word is either (a) No Access 2007 for you, or (b) Time to upgrade to Windows 2003 SP1 or later.

UPDATE: Definitely take note of the comment by Oğuz below that describes using JDBC along with the connectivity engine from Microsoft to create the datasource without having to use an ODBC socket.

Let's set this up. First, we have a data file named SomeAccounts.txt:

Josh
Mary
Suzy
Amanda
Trisha
Ben

Then, we have ProcessAccounts.bat, which we want to just loop through the accounts in the text file, tell us what they are, and tell us the first letter of the account name (just to have something to do):

Except when you do this, you encounter a problem: All of the values from the FOR loop are the same! It's as if the for loop ran the proper number of times, but it just ran on the last record over and over again! See below:

My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.
My account, Ben, starts with B.

What's actually happening is the FOR loop is indeed running over every line, and setting the variables as instructed, but the results of those variables being altered isn't echoed until the FOR loop is complete, so the last value of the variable is what displays. This wouldn't be a problem if you were just using your FOR parameter, in this case %%i, but any variables you set while in the FOR loop, like username, experience this "wait until you're out of the loop" phenomenon.

The fix is simple enough, if you know about it! But I've found the solution to be a bit elusive, which is the whole point of sharing it now.

The key is the setlocal EnableDelayedExpansion command. As explained at ss64.com, making this statement before your FOR loop will enable you to display variables as their value at the moment you're referencing them, or their "intermediate values" while in the middle of the FOR loop. In addition to calling the setlocal command, you then have to reference your variables with the exclamation point (!) rather than percent (%) to indicate that you want to use the intermediate value.

Your script will then look like this:

It will now happily act as desired, outputting these results:

My account, Josh, starts with J.
My account, Mary, starts with M.
My account, Suzy, starts with S.
My account, Amanda, starts with A.
My account, Trisha, starts with T.
My account, Ben, starts with B.

Using the Windows binary installer, I had no problem installing Subversion v1.4.5 on the server. I tested everything and Subversion still worked, it showed the new version when accessing via web access, and Trac still worked fine.

Alas: Don't forget that an upgraded version of Subversion will not upgrade your repository. It will upgrade a working copy of a checked-out repository, but it will not upgrade the repository itself.

That said, I was unaware of one more step that you must take to upgrade Subversion on a Subversion/Trac setup: You must also upgrade the Python bindings to Subversion.

This became apparent the next time I created a new repository, which was not a v1.4.x repository, and when I tried to build a Trac environment to point to it, Trac got upset because of the classic "Expected version '3' of repository; found version '5'" error. To fix this, you must set up new bindings to the new version of Subversion, as explained in the TracSubversion page.

Now, I obviously love Subversion and I love Trac, but honestly, straight-forward documentation that is easy to understand for someone who doesn't want to get in the thick of it isn't really the strong suit for these communities, at least when it comes to installation and deployment on the server. What exactly it means--and how to do it--when they say, "Update the Subversion bindings" is not easy to understand. However, the solution is simple. All that is needed is to download the appropriate "svn-python" Windows installer that matches your version of Subversion and Python (in my case, 1.4.5 and py2.3) and run it on the server.

In my case, I had to stop Apache for the installation to succeed. Upon restarting Apache, everything worked great.

So I was going through the SQL and making these changes. I came across a very ugly IIF() function similar to this:

Take that statement and add even more boolean fields. Clearly, the intent was to have a calculated field that had a friendly name based on which boolean field was true.

So, how can this be easily converted into a CASE statement? As it stands, CASE statements are actually more verbose than the IIF() function, and the IIF() function above is already hard to read and verbose as it is.

A direct code conversion would be something like this:

Ugly, ugly, ugly. The cool thing about CASE that differs from IIF() is that you can attack it from the other direction. Instead of saying, "Is phLead true? Is phFax true? Is phVVM true?", you can instead say, "Okay, who's true? phLead? phFax? phVVM?" It sounds negligible, but the code is shorter and easier to read:

Ahh, much better.

It turns out that NTLMv2, the authentication protocol, is required by default on Windows Vista. According to the Samba Features by Release wiki page, support for NTLMv2 in Samba wasn't fully developed until Samba v3.0.21.

Running yum would be a quick way to upgrade Samba to a more recent release. For some reason, though, the repositories I'm pointing to only have v3.0.10 as the latest available update. Rather than hassling with it, I found an article that attacks the issue from the Vista end.

The article Get Vista and Samba to Work explains how to get Vista to use the older authentication protocols, like the original NTLM. After making this change, I was able to login to my shares immediately.

Basically, all you need to do is run the Local Security Policies console snapin (secpol.msc), open Local Policies --> Security Options --> Network Security: LAN Manager authentication level, and change the setting from "NTLMv2 responses only" to one of the more lenient settings, like "LM and NTLM – use NTLMV2 session security if negotiated".

This works for me because I have one, sometimes two, machines with Windows Vista connecting to my server. If you had lots of machines connecting to the server, it'd obviously be worth your time to just upgrade Samba to a version that supports NTLMv2.

WinZip offers a WinZip Command Line Add-on free of charge--if you already own a copy of WinZip Pro!

You shouldn't have to pay for command-line zip. And you don't have to. Enter Info-ZIP. This workgroup has been maintaining free, portable, high-quality versions of zip and unzip. They have plenty of command-line arguments like you would expect from an open source project.

So, with this project's executables in your system path, you can write up a batch file that is executed as a Windows scheduled task. Maybe something like this:

This will zip the c:data directory. Arguments: -q to do it quietly, -S to include system files, -r to recurse into subdirectories. Finally, use -i to point to a file that indicates the exact files to include, by means of a carriage return delimited list.

You can alternatively use -x to specify only which files should be excluded. Perhaps something like this:

The command-line flags are all optional, of course. This tool is certainly a must-have for the Windows scripter.

Alas, I digress. The point is that IE isn't going anywhere for now, and it is a pain sometimes to figure out how to write CSS that renders as close to identical as possible between IE and other browsers like Firefox. There are several sites out there that endeavor to explain the IE bugs and, when possible, provide workarounds.

Sure, I could just alter the CSS to look right in IE, but if I'm not careful, that "fix" then breaks the code in Firefox! So we've come up with hacks to have CSS that other browsers will see but IE ignores. I don't know about you, but I'm tired of trying to understand and remember these tricks for satiating IE.

Welcome to conditional comments in IE. This is yet another IE-specific feature that we can actually use to our advantage to level the playing field.

Conditional comments are just what they sound like: HTML comments. But these comments are coded in such a way that effectively have a conditional statement in them, and any HTML output within the comments will only be included (by IE) if the condition is true. Here is an example.

As you can see, any non-IE browser will just ignore all the content, since it's really one large comment. But IE recognizes the conditional logic inside the comment and renders the content accordingly.

Here's an example. This box will have a message if you're on IE, and it will be blank if you're in any other browser:

If you wanted, you could use this technique to inject HTML elements specifically for IE.

Yeah. If you want a maintenance nightmare. Do not sprinkle conditional comments in your code.

Rather than having a CSS file littered with IE fixes (or just accepting the variances between IE and Firefox), I would much rather have a single "clean" stylesheet file that is then augmented by an IE-only stylesheet, loaded by IE and ignored by all other browsers via the conditional comments feature.

So, perhaps you might have some code like this in your header:

There is still a very real danger here. You don't want to fall into the tendency to write intolerant CSS that needs a lot of "cleanup" to look good in both browsers. Work hard to make your CSS as compatible as possible, and leave the ie.css file exclusively for the rare cases where you could not resolve an inconsistency in IE. When you're done, your ie.css file should be really small, if you require it at all.

Having said that, however, I think this is a graceful solution. You don't sacrifice the consistency of your HTML nor your CSS, and your only extra work is the tweaking done in your IE stylesheet. Other solutions like Targeting IE Using Conditional Comments and Just One Stylesheet over at PositionIsEverything.net recommend adding an IE-specific div tag around your content, which would enable you to have a single stylesheet and to not just include IE-specific styles but also exclude certain styles from IE. Unless you have some CSS that you just can't tweak for IE and you have to exclude it, I definitely prefer the simpler approach of just including a secondary, corrective stylesheet and leaving the HTML alone. But that's just the purist in me.

What's more irritating is that all of the images worked in Outlook Web Access; only the desktop client of Outlook wouldn't display some of the images.

The problem is that something like this is really hard to troubleshoot. After going down many different paths--such as assuming that I was attaching the image incorrectly, or perhaps that Outlook didn't like spaces in its inline attachments, and so on--I finally found the solution.

Outlook was recently patched to flag image references that have a src attribute with a capitalized CID. Thus, changing < img src = "CID:myimage" > to < img src = "cid:myimage" > fixed the matter.

Oh man. That’s frustrating. So I’m blogging about it in hopes that I might save someone who googled the issue like I did from wasting a couple hours of time.

Nevertheless, in her review entitled Uninspiring Vista, Erika Jonietz explains how Windows Vista, as nifty as it is in many ways, was the straw that broke the camel's back and caused her to appreciate how awesome OS X is and the entire Macintosh experience can be.

A great read for any Mac fan!

Unfortunately, some of us humans might try so hard to leverage our computer's multitasking abilities that the ultimate bottleneck becomes the limit of our own mental concentration. You're working on a document, but you also have your email client open and perhaps a few tabs on your web browser. Before you know it, you've wasted a significant period of time replying to email or going off on a tangent through the web, when the most important task at hand was just to finish typing up that document.

Enter WriteRoom. It may seem archaic by today's standards to boot up your computer into a word processor program and to only be able to use your computer for that purpose until you finish and boot into another program, but it sure didn't test human self-control and concentration like the systems we have today. WriteRoom duplicates that simple, distraction-free experience, and while you're at it, gives you a bit of nostalgic joy in the process. Sure, you could get a similar affect by opening TextEdit (on the Mac) or Notepad (on Windows), but where's the joy in that experience?

Did you grow up on an Apple ][ using AppleWorks with a green-on-black monochrome monitor? WriteRoom's default scheme duplicates just that environment. Did you have the DOS PC's common white-on-blue? Or can you just not stand anything but black-on-white? Fine, the color scheme is customizable. So is the font, so you don't have to stick with a monospaced font, although it sure adds to the nostalgia.

And the best part is that you don't have to give up the multitasking bit to use WriteRoom. You can run iTunes and download that huge file in the background, but experience a visually simple and uncluttered experience while working on your text document.

WriteRoom is for the Mac only, and the original version is free. A clone called Dark Room was written to respectfully "capture the essence of WriteRoom" for Windows machines, and is also free.

The ODBC services would not start, and although the "ColdFusion MX 7 Application Server" service was started, browsing ColdFusion pages received an odd error page:

500 NULL

There was a Macromedia TechNote about this matter, although it was unresolved as of the TechNote's last update.

Whereas a Google search will uncover many other times this error may pop up, my circumstances applied after the OS upgrade and on every single page view in its entirety.

The TechNote gives a good hint when it says the error can be caused by an empty or missing license.properties file. My answer was similar: The user that the ColdFusion service was running as didn't have permission, after the upgrade, to read from the CFusionMX7 directory.

I gave the user read rights and everything began working wonderfully.

Even though I think it is pretty blatant, for those of you who do not realize: David is using a common linguistic tool known as sarcasm.

There are graceful ways around the issue. You can (a) Reset one of the connections remotely, freeing up room for you, or (b) Connect to the computer's console session and then reset the sessions from a GUI interface.

Resetting connections remotely. This method is more graceful, but requires a bit more work. As Scott Forsyth described in Managing Terminal Services Sessions Remotely, the qwinsta (query windows station) and rwinsta (reset windows station) commands can help you accomplish this.

Use qwinsta to find a session to clear, or reset:

C:>qwinsta /server:MyServerName
SESSIONNAME USERNAME ID STATE TYPE DEVICE
0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
console 5 Conn wdcon
rdp-tcp#59 MyUserName 2 Active rdpwd

In this example, "MyUserName" has a session, and I could clear that session to take it's place. To do that, I would use rwinsta to clear the session, which has an ID of 2:

C:>rwinsta 2 /server:MyServerName /V
Resetting session ID 2
Session ID 2 has been reset

With the session being reset, I could now successfully login with Remote Desktop.

Connecting to a console session. Windows will always have a console session, which is the session that represents the session outputting to the physical monitor, if one were plugged in. If a user were logged into the machine and physically using the mouse, keyboard, and monitor that are plugged into the machine, and you then connected remotely to the console session, their session would be disconnected and you would connect to that console session. Obviously, this is not the typical approach you would want to take, but it is an option when you need to force yourself onto the computer.

Basically, this is accomplished by running Remote Desktop from the command line (mstsc) and invoking the command line argument to connect to the console session.

mstsc -v:MyServerName -console

That's all there is to it! At that point, you can either proceed with your work or use the console session to clear any other Terminal Services sessions in the Terminal Services control panel.

We love to quote it, because we love to hate Bill Gates and yet we can relate with the amazement of ever greater RAM requirements. For instance, I never thought when my powerhouse Mac came with 128MB of RAM that one day I would have a Mac with a video card holding more RAM than that! Insert similar nostalgic reflection here, ad nauseam.

Well, now I can just feel stupid and short-sighted without pointing the finger at Bill Gates. I never even thought to verify the quote until today for some unknown reason I decided to. Sure enough, you'll be hard-pressed to find an official citation, and Bill Gates denied ever saying that.

backup database MyDatabase TO DISK='c:pathtoMyDatabase.bak' with INIT

The syntax is pretty self-explanatory once you see it. Backup the database "TO DISK", or to a file at the designated path. The "WITH INIT" specifies that any existing backup file will be overwritten.

The restore syntax is nearly identical. If the database you are restoring currently exists, be sure to drop the database before doing the restore.

restore database MyDatabase FROM DISK='c:pathtoMyDatabase.bak'

Simple as that.