Ramon Smits

Change mssql isolation level to read uncommitted data

Sometimes you are debugging an application and want to query the database while the database connection still has not committed (or rollbacked) the transaction. So you fire up the query analyzer just to find out that you cannot see the modifications yet (ofcourse). Today a collegue of mine (Frank Bakker) found out that it is possible to read uncommitted data by altering the isolation level on a connection.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

When you have executed this statement you can now see all modifications that are still in a transaction. Isnt that neat or what?

The thing is that I used this some years ago in some functionality that generates reports based on website visits. The query did a select statement and it wouldn't be bothered if some additional records would have beed added to the table. You can get this behaviour by adding the keyword NOLOCK like the following example.

SELECT count(*)
FROM MyTable NOLOCK
GROUP BY MyCoolColumn

So NOLOCK and SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED are the same but the first (NOLOCK) is usualy best option as it is directly visible that the query needs a different isolation level. Setting the isolation level seperately can ofcourse increase readability is your query does a lot of joins though.

You can also do this in MySql in almost the same syntax as shown below.

SELECT count(*)
FROM MyTable(nolock)
GROUP BY MyCoolColumn

Happy 'reading'...

Subversion troubles "PROPFIND request failed on '***' '***' path not found"

I created a repository at opensvn.csie.org today for the website I created with a friend for the volleybal club. We really needed version control because we are both working on the project at the moment plus that I really don't like all those *.old *.old2 *.old3 files hanging around :-)

So I committed the various data of the project to the subversion repository and after that wanted to branch it to identify the site that is currently live. I started the command prompt and use the svn copy action to tag the current development branch.

svn copy \
https://*/yumwebsite/trunk \
https://*/yumwebsite/branches/v0 -m "Version 0"

After running the command it failed with the following output:

svn: PROPFIND request failed on '/yumwebsite/!svn/bc/2/branches'
svn: '/yumwebsite/!svn/bc/2/branches' path not found

My first thought was that the opensvn.csie.org was at fault but quickly I realised that wasn't the case. So started googling what I was doing from. The problem was that the folder 'branches' really did not exist just as the error said. But somehow I blocked that error message in its exact form. So after adding the branches folder the the project root the copy action ran error free. The stupid thing is that I had the same behaviour a while ago. So I decided to post this for my own convenience in case I forget it again.

Website design not my favorite hobby

Although I am an ict nerd and resulting affection for bitfucking and neverending refactoring I also do some sports. I play volleyball and the current website of my volleybal club yum lacks some general design that works correct on both firefox and internet explorer. I'm a member of this club for some years now and I didn't like the design from the start. So while a friend said he was working in his spare time with a redesign of the website internals I proposed to help out. I don't know why I said that because now I'm screwed :-)

My main objectives for the site are:

• No tables for the websites design.
• Crossbrowser.
• Not too much graphics.
• No frames.
• XHTML proof
• CSS validation proof

So I made a design by hand with my *excellent* css and crossbrowser knowledge (%$*@ crossbrowser makes me insane!) and within a few hours I had a design I could live with as a first draft for reviewing. I ofcourse lied a bit about my css knowledge as I''m a 'back-end boy'. I like to play with photoshop but really lack the skills of creating a good gui or website design. The current version looks quite ok if you don't mind that I judge my own work. Below some WIP screenshots of the design.

Below the proof that my website is non CSS friendly.

Don't use viewstate compression! Use http compression instead!

Just google a bit with the keywords compression plus viewstate and lots of articles are to be found about this subject like this one. The problem is that in most situations programmers are doing something that the webserver already can do for you. Not only does it compress the viewstate, it compresses all (dynamic ) documents that you configure it do to. It becomes even worse when the webapplication compresses its viewstate and the webserver compresses the rendered page output *again*. Seems a bit inefficient to me :-)

So let the webserver do in what it is good at. Serving/streaming rendered documents to the browser in the most efficient manner. Just configure it so that it is also compresses dynamic pages. If you dont know how to do this then just google on http compression iss and lots of articles that explain how to achieve this. It really doesn't need an extra article from my hand ;-)

One situation in which it could be of interest is when an http 1.0 browser performs a request which does not support gzip compression. This way you can achieve nice results by compressing the viewstate. But in the article mentioned at the beginning of the page can be read that the viewstate would sometimes be larger then 1 megabyte. Well if that is occuring in your application then the viewstate data must be *really* expensive to calculate or read from a store must it be that important to add as viewstate data. In most application retrieving data from a data source actually performs very well although it always depends on the total count of page request, the total amount of webservers in a farm and the number of databases as is the kind of state required for some functionality.