I decided to hash together a quick and simple survey component for this blog (to be released publicly as open source as well). While the data access is via interfaces and dynamically instantiated helper classes, and thus data source agnostic, the first concrete class I decided to make was one that uses Microsoft Access as the back-end data store. For low-end uses like this the performance of MS Access/JET can be more than adequate (the non-transactional performance can actually be superior to SQL Server in some scenarios). Using the OLEDB ADO.NET components made pretty quick work of it, and it is refreshing to go back to such a simple, file-based data store, versus the SQL Server and DB2 architectures that I've been using for the past couple of years.

Just to validate that Access could offer the desired low resource usage, along with the capacity to handle the odd spikes in volume, one of the first tasks was a quick benchmark to test my data methods. I was shocked to see how slow they were. As a bit of background, I always strive for minimal resource usage, using features such as dispose patterns (keeping connections, commands, and other resources active for the minimal amount of time), relying upon the connection pooling of the underlying data providers to decide when it was appropriate to tear-down connections. This is critical in web apps and web services.

Anyways, long story short - Access, and the other OLEDB->ODBC data providers, do not by default enable connection pooling. What this means is that each time my method was hit it would reopen the file, reorient itself, get the data, close and release the file, all to repeat it again on the next iteration. This is absolutely terrible for scalability, which I saw demonstrated in my little test.

What I discovered (and this is old hat for Access developers, obviously) is that you need to add OLE DB Services=-1 to your connection string. With this directive, OLEDB turns on connection pooling. The results in my test were overwhelming, and the performance increased dramatically. This is obviously old hat for people who regularly target Access, but for the Access part timer it is probably a thief stealing their performance.

After the laborious process of uninstalling all of a prior .NET 2.0 beta, and then installing SQL Server 2005 on one of my dev machines, now the Visual Studio 2003 install (which of course utilizes .NET 1.1) is spitting up with an automation error, refusing to run. So now I'm stuck with repairing that install, unsure what exactly is causing the issue (I didn't install Reporting Services, so why this impacted Visual Studio 2003 is a mystery to me). [UPDATE: A repair did nothing, and there are no google hits that describe the same symptom, so now it's a full uninstall and reinstall. A quick project I wanted to bang off in the small amount of time available has already had most of the available time eaten by this sort of issue]

I appreciate that I should try betas on virtual machines, and often I do, but maintaining and configuring virtual machines is a time consuming process, and for some installs I expect there to be some level of side-by-side capabilities. I never had a problem with any of the prior betas of VS.NET 2005, or SQL Server 2005, so who knows.

As, err, "regular readers" know, I just started this blog a week and a half ago. Since then I'm up to around 400 visitors a day in here, which I'm pretty satisfied with given the limited amount of content thus far (though I think it's pretty good for a week and a half! Apart from a couple of dedicated, focused efforts, most of this has been off the cuff commentary, but it really adds up quickly. I could imagine the corpus of info that will exist here in a year).

Nonetheless, I would like more traffic, to the point that I'm saying "Scoble? Who's that?".

One of the ways to drive traffic to a site is through the use of Trackbacks. This mechanism, at its root, is a quid pro quo arrangement between blogs - e.g. I post a brief summary of something a "big" blogger said, and then ping their site with a trackback. They post the trackback link and users, and search engines (and PageRank if nofollows isn't put into force), go both ways. You pat my back, I'll pat yours. As mentioned in a prior posting, I currently don't have trackbacks or comments because of the slowness of the Radio Userland servers, not to mention that it would be a hassle to monitor it for spamming. I investigated implementing my own trackback server (it's a very simple spec), but the current industry belief seems to be that trackbacks are dead because of spam (which is a funny claim, because trackbacks are pretty much by design a type of targetted spam).

So for the meantime I am going to continue to monitor referral logs, as I always have, and if I notice someone coming from a link or post on your site, and I can validate that it's real, then I'll add a note on the posting. Basically it's a manual trackback system.

Over the past couple of days there has been a lot of discussion regarding some new, higher density flash memory devices. While I don't think a doubling of density is all that remarkable or technology shifting (flash is still quite slow compared to a modern hard drive. This isn't to discount it, and there are a tremendous number of very valuable uses for such a solid-state, low-power technology, but just wanted to mention that it isn't a panacea and there are compromises), what fascinates me most about these sorts of discussions is the metrics articles use to help people understand capacity. The article linked above states that "By combining 16 of these, manufacturers get 32 Gb[GB - sic] of flash memory that can store more than 32 hours of HD video files, 8,000 digital music files (670 hours), or 200 years of daily papers.". Woo, 200 years of daily papers (all papers? One paper?). Remember when the standard metric was the number of copies of the King James Bible? I never knew how much space the Bible would actually require, but it sounded like a lot when something could hold multiple copies of it.   [UPDATE: Looks like it's about 4.8MB uncompressed, so a 32GB flash card could hold 6,826 copies. Sounds impressive. But how many "Libraries of Congress" could it hold?].

As flash memory starts to compete with hard drives, operating systems will need to mildly adapt. For instance, flash has a limited lifespan, with localized degradation each time you erase a block: The common behaviour for operating systems to page out blocks of memory to the storage system unnecessarily, such that Windows does regularly, and to endlessly create and destroy small temporary files on the filesystem. Either wouldn't be a wise thing to do with flash. It will be a good thing as operating systems adapt, as I'd love for my hard drive to actually power down when I'm not doing something that actually requires its involvement.

At the beginning of the year I published parts I and II of the SQL Server High Performance Series, promising Part III "soon". This series was very well received, and garnered some great feedback and encouragement, but then I got overloaded with other things (primarily the birth of my second child - my son Weston).  

Well I have finally dedicated a bit of time, and plan on wrapping the series up over the next two weeks. While it isn't the most indepth or profound guide on designing for performance, it does contain tips and tricks that experience has shown me most database implementers (most of whom are part-time database designers by necessity) don't know.

Several readers have written to me over the past while, asking for an update to an article that I wrote for the July, 2003 issue of MSDN Magazine. In that article, I expressed a lot of optimism for the future of Scalable Vector Graphics (SVG). However, based upon how the market has evolved since then, and the amazing clarity of hindsight, I have come to believe that SVG is effectively dead as a mainstream, desktop technology. To many this will be a painfully obvious fact, but I thought it had to be addressed (and it allows me to respond to queries with a courteous link). 

SVG, as a quick primer, is a vector graphics technology that allows for gorgeous layered designs using basic primitives. SVG also offers a wonderful DOM programming facility to allow for animations and programmatic alterations - I won't go into SVG in technical detail (not only are there plenty of resources out there that do, but I also don't pretend to be an expert in SVG), but I will say that in a nutshell SVG is a standardized, owned-by-no-one alternative to Flash: With a simple XML layout and clear, logical specifications, SVG was compelling in its approachability and low barrier to entry - No special authoring kits, or understanding of convoluted binary formats, was required to begin creating dynamic, vector-graphic solutions.

Nonetheless, based upon some observations and occurrences since, I will confidently state that SVG is dead on the desktop:

• Adobe has been the primary sponsor of SVG since the outset, and many believed this was largely to undermine Macromedia's Flash
• Adobe, whose plug-in viewer is by far the #1 method of client-side SVG rendering, hasn't meaningfully updated their viewer since 2001
• Corel also created an SVG viewer, but it too has completely stagnated, and that element of their graphics strategy has faded
• Even the Apache Batik project has largely stalled
• Macromedia released the Flash File Format Specification, undermining one of the primary selling points of SVG
• Flash is ubiquitous
• Adobe acquired Macromedia for $3.4 billion in a deal that was approved on August 24th. Flash is an absolutely critical ingredient of Macromedia's business model. Adobe didn't put $3.4 billion towards something they plan on killing
• The remaining push for SVG seems to be for the mobile market, but even there Flash is making headway
• I was sure then that the open standards SVG would be heartily adopted and evangelized by the open source community, and I felt certain that mainstream, native support for SVG would thrive in Mozilla cum Firefox, giving it a killer-feature to take on Internet Explorer. What SVG support exists today, over two years later, is still just a fork that is described as a "technology preview"
• Microsoft is going to capture hearts and minds with XAML, and with tools like Microsoft Expression (which doesn't, to my knowledge, support SVG).
  

These, along with other factors, have led me to believe that SVG on the desktop is a non-starter, barring some jarring schism in the marketplace. I think it's too little, too late for Firefox to offer a wide deployment of SVG, and I doubt Adobe is going to do much more than let SVG fade away (of course they'll claim otherwise, but let's be honest).

I do, however, continue to believe that SVG on the server, as a component of the image processing pipeline, is still entirely viable.

[UPDATE: A followup can be found here]

I try to keep on top of the various important releases from Microsoft, testing assumptions and seeing what's new with each release. Tonight I decided to install the September 2005 CTP of Microsoft SQL Server 2005.

While it seems like a pretty trivial exercise to update to a new release - and from a difficulty perspective it is - it is remarkable how much time each of these iterations takes. While I don't need to sit here looking at the screen for the duration of the install, there nonetheless is a lot of user interaction that is necessary (even if it's just saying okay to random dialogs), and it soaks up PC resources for quite some time. First one performs all of the various deinstalls of the prior iteration, and the lengthy installs of the new one. Add in various incompatibilities just for fun. "Whoops, I have the Visual Studio July CTP .NET Framework, which is conflicting with the September CTP of SQL Server 2005". Almost sounds like ".dll hell". Of course to really keep on top, add in all of the CTPs of Visual Studio, and the other tools. You can basically fill your days uninstalling and installing various tools.

There is no real "point" here, and I can't see any possible solution (except for perhaps completely touchless installs that require zero interaction from setup.exe to finish), but it could be the reason why so few people seem to have any hands on experience with either SQL Server 2005, or Visual Studio 2005.