Jon Baker's Outer Join

A friend of mine, Scott Swisher, passed along this information.  I thought others might find it interesting.  SharpDevelop is an Open Source IDE for .NET development.  While not complete, especially for ASP.NET, it is interesting to see where they are going with it.  I haven't played with it yet, but I plan to.  Has anyone else used this?  Any interest in such a thing?

http://en.wikipedia.org/wiki/SharpDevelop

Basically, you can find this information in a few other places, but it took me a little while to find, so I thought I jot it down, so I remember and in case someone else thought it was useful.

First of all, I want to thank Kirk Haselden for his fine book on SSIS.  It has truly been a lifesaver in developing SSIS standards for a customer. In his book, Kirk talks about the "magic folder" for SSIS.  This is the folder where the SSIS Server looks for packages.  Essentially anything with a .dtsx extension will show up in SSMS when managing an SSIS instance.  By default, this is a folder buried deep in the bowels of Programs Files, namely C:\program Files\microsoft sQL Server\90\DTS\Packages. This is a relative path to the install (..\Packages), so it can also be moved if you move the install location for SSIS. 

Just as Kirk describes in his book, you can change the location of the magic folder by editing the config file, MsDTSSrvr.ini.xml, changing the StorePath value (p.383).  You can also add more StorePaths to have multiple file locations for SSIS to look.  But you can get this just by reading the book...

Now for the good stuff. We wanted to have a known location for our SSIS packages, not the relative path that comes in the default config.  We wanted to hang the store off the root of the E: drive in the SSISPackages folder.  It wasn't documented anywhere, but there was a hint of it in Kirk's post about clustering the SSIS service. The path doesn't need to be relative, it can be hard coded to a drive letter if you like.  We changed the StorePath value to E:\SSISPackages, restarted the SSIS service, and voila, we could see packages in the folder via SSMS.

Again, you can find this information in a few places but it wasn't explicit.  Hope this helps someone other than me.

Jon

Bumped up against and interesting problem today.  Seems that Management Studio by defaults save your code as Unicode, UCS-2 to be exact.  Previously, Query Analyzer saved files in ASCII text format.  You might be saying, who cares!  Ah, but if you want to use source control (especially non-Microsoft flavors), you might.  We found the problem when we realized that files were being checked in as Unicode, and our deployment automation tools were not working.  At my current client, we use Borland StarTeam for Source Control. StarTeam was treating the files as Binary, which meant we couldn't diff, merge, search, etc. 

Well after a bit of research, there is a work around for this UNICODE vs. ASCII problem in SSMS. You can save as something different by clicking File | Save (or Save As…). When the dialog box appears, click the drop down on the Save button. Choose Save With Encoding

Another box will appear allowing you to choose ASCII text. I could find no way of making this the default, so if someone does posting it would be appreciated.

So if you want your developers to be sure their files are ASCII, this is the only way I could find. Here's a less than politically correct opinion from HsuGotaQ on a blog. http://hsugotaq.spaces.live.com/blog/cns!B10E712EC5D7D360!863.entry. Thanks for that input. 

In his post on DB Snapshots, Andrew Calvett offers some great examples of how to use DB Snapshots.  I'll offer another. 

I currently work with a General Ledger and Accounts Receivables system that has some large batch cycles.  Testing for these behemoths can take hours at a time, which only changes a fraction of the database.  A second run of a batch test sometimes must wait on a database restore, which severly limits the number of test cycles in a day.  I'm working to use snapshots to speed up the database restore time, allowing the QA team to get more than 1 test per day. 

Pros :
Restore performance could be greatly increased
More testing = better code (or so you'd hope)

Cons:
If the batch changes a lot of data, size could be a factor
There will be some performance overhead as a write to the source DB means a copy of the page to the snapshot DB.

What do you think about database snapshots?  How are you using them?

Jon