This blog contains reflections and thoughts on my work as a software engineer

Viser opslag med etiketten tip. Vis alle opslag
Viser opslag med etiketten tip. Vis alle opslag

torsdag den 21. august 2008

SQL Profiler tip

Ages ago I discovered a nice little feature in SQL Profiler to enable you to only see the queries which comes from your machine. Very useful if you are not the only one using a database and want to track down which queries you are responsible for initiating from your local machine. I assume that you have basic knowlegde of SQL Profiler and trace templates - otherwise you should read more about this fantastic profiling tool before you proceed.

Here goes:

  1. Start up SQL Profiler
  2. Choose File --> New trace and attach to your database
  3. Click on Show All Columns - and whoops: Up comes the column "Hostname". Choose this column for every event you want to appear in your trace.
  4. Click On "Column Filters"
  5. Find the "Hostname" column and enter your computer's hostname in the "like" field
  6. Save your trace as a trace template - name it i.e. "MyComputer"
Now - this is the sweet thing - you can fire up SQL Profiler and trace every query which comes from your machine. All you have to do is to choose the trace template "MyComputer" and start tracing calls which only you have started.

I find it extremely powerfull because it enables you to debug single lines of code in Visual Studio and monitor exactly what SQL is hidden behind various peeks and pokes to your domain model. I use it about every time I use SQL Profiler - I couldn't live without my personal trace template.

Nothing magic about it - just one of these mighty fine things to have in your debugging toolbox I guess ;o)

Regards Kristian

fredag den 25. juli 2008

Javascript != Internet Explorer

I had this funny experience today with this little piece of Javascript:

function Redir(sAcceptUrl, orderId)
{
document.location.href = sAcceptUrl + "?orderid=" + orderId;
return false;
}

The function was called by a button's onClick-event like this:

input id="theBigRedButtonGoesWild" onclick="Redir()" type="button

This worked fine in IE but not in Firefox.... Firefox just posted to the same page and didn't care very much about the document.location.href change - What the hey ???

It turned out that when using this little function in Firefox you have to use the return value of the Redir() function in order for the Firefox event model to NOT perform a postback - like this

input id="theBigRedButtonGoesWild" onclick="return Redir()" type="button">


It has something to do with the fact that a button in Javascript is actually always a submit-button and inherits it's behaviours from a world which posts back if nothing else is being dictated. IE's event model is - well - different ;o

This was just a quick one - I am on vacation for 3 weeks starting in about 5 hours (first thing on my todo-list: Go to the parent's house and mow their lawn because they are on vacation...) so this blog will be on hold until I am back from work

Regards Kristian

torsdag den 20. december 2007

Constant requiring explicit parsing == evil

I'm working on a project which includes the use of a service-enabled image uploader and imageviewer. The service defines a load of constants and properties in web.config which is fair enough.

However, when porting the assemblies to our local machines (we run all services, source and subsystems on our local machines to be able to work truly disconnected) we discovered a strange error while attempting to upload a test image to our service. Due to a lack of logging within the imageservice itself the cause of the error wasn't appareant at first but a quick review with the programmmer in charge of the imageservice reveiled that it was an issue with the configuration file.

One of the constants in the configuration defined a maximum height and width of an image being uploaded. If the size exceeded the maximums defined the upload would be rejected. The constants were defined in this way:

1024;768

What made the imageservice burp on our local machines had something to do with our regional settings which caused the configuration to try and interpret 1024;768 as an integer.

With our retrospective cap well in place what could / should have we done better to avoid such a problem from occuring?

- Never define constants which require explicit parsing to become valid
- If you decide to do provide detailed logging before and after the parsing occurs
- Take into account within your software that machine regional settings are - well, machine dependent ;o)