So this weekend was my brothers graduation and all the family came over big party the whole 9 yards. I was having a conversation with my cousin in law who is a dentist and the subject of humility in ones field came into play.

How the Customer (or Patient) would rather feel the sense that you are going to make things ok and get it done, but at the same time treating them as an equal or better yet a person. Not just someone’s that going to write you a check.

I think sometimes we loose the human interaction between both parties. For example here a situation that happen to me.

My DSL was acting up so I called tech support, person on the other end walks me through steps that they are reading off the screen. We thought the issue was resolved and i was giving a ticket. 30 min’s later my DSL goes down again, I call back and give them the ticket number and they proceed to walk me through the same step, even though I told the guy and he knew I had been through this wasting both our times. If i wanted that kind of service… i would have much rather preferred an automated system, at least an you known that the automated system doesn’t think and cant expect to much from it. And so now next time I call back I’m going to be a little negative about them helping me.

And thats the important part making the customer feel like you really tried to help them not that there just an Item in Queue…even if they are just an item in queue.
…this is the end to my rant

I found these two articles very informative, In many of my project the user log in through a form and are validated against AD. From there i would create a NetworkCredential that i would pass to the sql reporting webservice. This is another method you can use to provide sql reports with out having to hit add.

Using Forms Authentication in Reporting Services:
http://msdn2.microsoft.com/en-us/library/aa902691(sql.80).aspx

Using SQL Reporting Services 2005 and Forms Authentication with the Whidbey/2.0 SQLMembershipProvider
http://blogs.msdn.com/bimusings/archive/2005/12/05/500195.aspx

A good friend forwarded this Why Top Employee’s Quit.
This is usually and issue that top Exec’s don’t even get to see, because it’s handled by middle managers or they have it’s not my job attitude. It’s all about the environment my favorite quote from this article is “$30K a year with a company full of stiffs is worse to me than $28,500 with a fun energetic company”

It’s a good little read and very informative

Another Good link from the same site is 50% Ways a Manager Can Get Employees to Quit

I was thinking about a couple things….yea i know “max you think?!?!?’

Did you know that the RaisePostDataChanged event is called after all your Load events are called, and this is right before Your postback event is called. This is so that you cant muck up your data on page_load() before it gets to your lets say Textbox.Click event.

Why is this help full to us, well this means that on page load or pre init we can see if the control has changed since its last postback. How?

Well you can still get to the new data from the Request object using the controls ClientID.

You can to this by Request.ServerVariables[Control.ControlID]

so we can create a method like:

public bool hasChanged(TextBox ctr)
{
return Request[Control.ControlID].Equals(ctr.Text);
}

its just the simple and we can subclass any control and do that.
we could also save the original loading value into viewstate.

I started to search for more information on what i was doing found a good posting from Steven Swafford On Using Application Cache for viewstate.

His post also refers to a asp.net podcast that talks about the same thing. It is good if your application is on one server or Your farm is using sticky session. But it is still a good idea, i emailed him asking permission to take some of the code and create a Viewstate Storage medium for ViewStateEliminator.

I have hit a small snag when it comes to the average life expectancy of and keeping its viewstate around. should I really keep it around anymore than a couple of hours. I understand that the point of viewstate was to have a way to rebuild the control tree with out having to keep the information on the server.

But the increasing size of viewstate to client is becoming alarmingly large on the complex and large web applications.

a solution that a friend of mine sugested is that if we use SQL server as a storage medium only keep viewstate up to 24 hours and then simply delete them. Or through a configuration in the web config