To be continued...

Check out my blog’s final resting place: http://www.signaturesterling.com/blog/

There’s just no place like home…

Good Times with GridView's

Don't worry GridViewGuy...I feel your pain - http://www.forums.gridviewguy.com/ShowPost.aspx?postID=350

Bootcamp Character

Every once in a while I stumble onto a personality so bizarrely charismatic and fascinating, it’s difficult to avoid being captivated by their presence; much the same way one cannot look away from the gory road-remnants of what used to be a human being while driving by a horrific traffic accident. I encountered one such personality in an unlikely location: while attending a Microsoft Professional Developer Certification two week boot-camp course in Atlanta, Georgia earlier this year (a separate topic that deserves a blog thread all its own, but we’ll reserve that for another time).

The man they call ‘Chester Flake’ was not only my Microsoft boot-camp instructor, an accomplished developer, Database Administrator, and overall .NET expert-turned-trainer, but has also dabbled seriously in policitics, stand-up comedy, acting, real estate, owned a slew of businesses, and all with more than enough personality to fill up a large building.

Sure, we wasted some classroom time listening to his fantastic (and remarkably true) tales, but honestly I was grateful because without his daily bizarre antics, I stood little chance of remaining conscious during class since, true to its ‘Boot-camp’ title, the course came complete with severe sleep deprivation and hideous study schedules. In addition, the man they call Chester Flake was a fountain of .NET knowledge and there was little I could quiz him about that he hadn’t already encountered in his own development experiences and could answer to. As such, he was able to side-step many of the tedious, fundamental elements of the curriculum and present more advanced, highly tangible and applicable lessons for those of us who were already developers, making very efficient use of the classroom time we had and reserving the fundamentals for individual learning.

All-in-all, if you’re ever faced with the choice of a mundane hoo-hum instructor to lead a course you’re attending or a slightly insane, completely maniacal one; I suggest the nut for 2 reasons. First, you will find it much easier to stay awake during class and second, chances are he or she is very good at what they do since otherwise they would’ve been terminated long ago for offending the office staff with their off-color and eccentric sense of humor.

Things that make me go...wuh?!

Would someone pleeeeez explain to me what is up with police officers in this city?! I have been pulled over more times in my short 2 year residence here than the rest of my entire life while residing in Tucson, Arizona. But it’s not just the frequency with which I get pulled over, it’s each and every officers’ condescending, offensive, and just generally impolite demeanor virtually every time I interact with them.

Some of you may, at this point, mistakenly dismiss me as nothing more than one of those speed-demon, criminally negligent cop-haters, but nothing could be further from the truth (except maybe a bit of the speed-demon part). I’m one of those unusual people who happens to agree with the laws we have in place (or at least recognize their necessity to preserve my security) and, with the exception of the occasional speeding or parking violation, I refrain from ANY criminal activity of ANY kind. Furthermore, I have never had anything but the utmost respect, admiration, and reverence for individuals who put their lives on the line everyday to protect my way of life.

In addition, I never, in my 27 years of living in Tucson, felt disrespected by a single police officer I interacted with nor did I feel badgered or profiled. I have suffered each of these while interacting with San Diegan officers on multiple occasions since relocating here. It’s common knowledge that any career field is going to attract some bad apples, but the volume, frequency, and misery of my interactions with police officers in this city has led me to believe the majority of its officers have adopted this unpleasant demeanor and approach to interacting with their citizens.

I’m well aware of the disparity between populations and subsequent crime rates among the cities of Tucson and San Diego and can only assume that the latter’s harsh urban environment is what has shaped these good-intentioned officers of the law to become so jaded, bitter, and cynical towards the general population. I can only imagine the devious criminal scum and life threatening scenarios San Diego police officers must be faced with on a daily basis.

But, unfortunately, some of San Diegans’ ill-tempered attitudes towards police officers (like my own) are self-fulfilling prophecies in the form of a defensive reactions against the officers’ inappropriate aggression and mis-use of authority. Any socially-skilled individual will agree that it’s necessary to adjust one’s demeanor and aggression level depending on the details of the situation at hand. Why is, then, that I feel like a convicted felon nearly every time I interact for any reason with a San Diego police officer? Why should I, a strictly law-abiding and highly productive citizen be treated in such a manner? I am always nothing but absolutely respectful during all my encounters with police officers, in spite of my rapidly developing aversion to them; why should I not receive the same respect I’m providing?

It’s tragic that, with all the adversity already directed at a police officers courtesy of the plentiful number of legitimate criminals out there, officers must also endure offensive behavior from law-abiding, respectful citizens who are simply irritated by the authorities’ unnecessarily abrupt, condescending, and patronizing manner. Furthermore, such superfluous adversity is easily avoided by remembering that, in spite of the excess number of scandalous deviants, most of us are still morally-upright, virtuous, and honest citizens just going about our day who want nothing more than to be treated with the same respect we give. After all, those among us who agree with the laws and their enforcement (or at least their necessity for our secure way of life) are ultimately on the same team and serving the same purpose as those in law enforcement, so why treat each other as such?

Gaaaaiiit Uuuurr Paaaawwwpkorn!!!

I don't think I could ever be successful in a position requiring predominantly sales skills. I'm too much of a WYSIWYG [whiz-ee-wig; 'What You See Is What You Get']. That's not to say that my opinion of successful sales people is that they're a bunch of big superficial liars, but I do believe sales arena success requires a certain level of embellishment along with a high degree of (sometimes forced) enthusiasm. And I just don't got it.

That said, I have a tremendous amount of respect for those that have found success in a field requiring, not only superb communication skills, but also confidence, competence, ridiculous hours, and the 24/7 enthusiasm of a beauty pageant contestant; I get exhausted just watching them.

Well...I do DEE-CLAY-AIRE...

First, I must apologize to my frequent blog-reader [singular] for the recent lack of new postings. Unfortunately, my company's firewall recently added www.blogger.com to their 'restricted list' which means no more workplace postings. Nevertheless...I will not be silenced! "The Man's" futile attempts to squelch my free-speech frenzy shall not succeed; my voice will continue to echo across the mountaintops of Blog-land!

Anyhoot...onto the bloggin' topic: The savage .NET 2.0 battle rages between declarative server control initiation versus programmatic server control initiation and maintenance. Here is one such fellow blogger touting his preference for the pragmatic, programmatic methodology.

And here's my 2 cents: When first introduced to asp.NET 2.0, I, too, found the declarative server tags and DataSourceControl-populating wizards somewhat disconcerting, creepy, and a little too Dreamweaver for my taste. "I'm a real programmer", I kept thinking, "I've dredged my way through the ugliest, most-cryptic of programming coding (that's right, I've had to work with Prolog) and I certainly DON'T need any wizard to do my programming for me." I was suffering from what the professionals like to call 'Old-Skool-izm'.

Relatively soon, it became quite clear which side of the coin Microsoft's developers had contributed vastly superior resources towards planning, implementation and even documentation efforts; the declarative side. After MANY frustrating scenarios (and multiple blog postings) working with a variety of server controls in a stubborn, strictly programmatic manner, I found myself fixing many of the inexplicable, unintuitive server control symptoms and behaviors by simply switching to declarative mechanisms.

As time rolled on, and continued to plunge headfirst into the code-reducing, time-saving declarative devices, I found myself wondering why I had so fervently resisted them for so long. Certainly there are times when a programmatic method is necessary for a certain echelon of dynamic server control behavior, but when it's not; why write more code than I have to? And furthermore, why not allow Microsoft's framework to invisibly do the heavy lifting for me in terms of maintaining a control's state?

On that note, I recently discovered what I considered to be a somewhat obscure ViewState symptom of populating a server control programmatically rather than declaratively. If you rely on a server control's view state to retain its data across postbacks, so that you’re not required to continuously re-load the control every time the page refreshes, asp will store your entire data set for that control in view state (that’s about 136 lines x 1024 characters worth of view state for a single DropDownList control populated with approximately 5000 records). This is because all changes made to server controls via the code-behind file are lumped in with asp’s interpreted "user-initiated control changes" and so are preserved within view state rather than stored server-side.

Alternatively, declaratively binding a server control to a DataSource object, such as a SQLDataSource or an ObjectDataSource, will store the control’s associated dataset server-side eliminating the size-able view state that will travel to/from server and users' browsers for each page request.

Similarly, any property setting changes made to controls in a programmatic manner, such as the control's styles, maxLength, databindings, etc will ALSO be recorded and maintained within the page's view state. Is one's view state really a consideration when we're talking about view state hogging rich server controls such as the GridView? Probably not, but it's food for thought.

Hip-hip...Aaaaaarrrraaaaayyyyy!!

There is simply nothing more fulfilling and gratifying in the world of software development than solving a tough problem with an elegant, robust and scaleable solution.

Welllll...except for googling your problem, standing on the shoulders of other programming geniuses, and using their elegant, robust, and scaleable solutions to solve your own tough problem. Programmers are inherently lazy and I'm no exception. So when I stumbled onto this little URL gem describing an elegant, scaleable, robust and plug-n-play-like method to providing integer array parameters to a SQL stored procedure; I thought I'd share it with my fellow engineers.

TSQL Integer Arrays

I'd be interested to see the performance variance in high volume queries (like say oh, 40,000 records) between utilizing this method as compared with just providing a giant string delimited varchar parameter, concatenating, and executing it.

Psssshhaw...A man's world - hah!!

Sure, I took my share of Women's Studies classes at the University because, much like the sociology courses, they were some easy upper division credits. I even briefly considered minoring in the subject, but, while I found some of the topics to be quite fascinating and educational, I noticed a common theme, nay, a common atmosphere among them all:
Woe is me, a minority, living in this cruel WASP world! How will I ever survive? More importantly, how did I ever make it this far?!

I believe there is a time and place for empathetic sympathy, but not when it comes to one's minoric [copyright, patent pending] gender. In my opinion, adversity just makes one stronger, smarter, faster, and more driven than everyone around them who got there without facing their own comparable adversity.

Would I choose adversity if given the option? Honestly, I don't know. Does that make me crazy? Maybe, but I have to consider the fact that others doubting my ability or criticizing my efforts generally just makes me try that much harder and want it that much more. So, would I have achieved as much without some adversity? Honestly, I don't know.

Male-centric arenas I have already invaded and subsequently conquered:

• Software Engineering - Roughly a 1:20 ratio in computer sciences' course enrollment.
• Motorheadism - I can personally attest to the lack of female presence within this realm. In the 3 times I visited the drag strip with my car, I only witnessed one other female racer among countless males. The racetrack course I attended also contained 1 additional female other than myself among approximately 50 males.
  
• Definite and perpetual financial independence - "All the honeys who make ur money...throw your hands up at me!".
  
• An emphasis on one's career/educational development and accomplishments for personal fulfillment and gratification rather than only one's personal life/experiences - Ladies, let's be honest. Despite what your college transcript indicates, how many girls out there were/are really pursuing their 'MRS.' degrees?
  
• The Weight Room Squat Rack - I've never seen another girl doing free-squats at my gym and, judging by the expression(s) on my fellow lifters' faces, neither have they. Sure, it took some strategizing to figure out how to 'manhandle' the 45lb Olympic bar above my shoulders, but now I'm a regular pro.

Future male-centric arenas I plan to invade and conquer:

• The motorcyle portion of Motorheadism.
  
• Software Architecture - I don't know a single female software architect - all the more reason to subdue and conquer.
• Stand-up urination [kidding...I can already do this; just not very accurately].
  

The purpose of this bloggish narrative is not to tout my own ferocious drive or my personal accomplishments, but rather to inspire other to create their own. I've pursued and conquered these arenas for no other reason than they piqued my interest and I was fortunate enough to have a father who never treated me like a daughter, but instead like a child, and a mother who worked hard to keep from squelching my fierce independence (and occasional stubbornness). Everyone should be as lucky as me. But if you're not, who cares?!

Never, ever, ever, ever, ever limit yourself according to someone else's standards or limitations. If you have an interest or a curiosity, as non-status-quo as it may seem, pursue it. If you don't understand it or are intimidated by it, start asking questions or find some education. Bottom line is, your only limitations are the ones you impose upon yourself.

Offensive Omnipotent Oo-glers

We've all seen them before (or more appropriately been seen by them); those guys who so blatantly and fervently oo-gle that a simple 2 minute conversation is disconcerting. I'm not talking about the testosterone-driven, 20 something's who gawk at the chick in the bar wearing the barely there skirt and halter top; she's aspiring for such attention.

The dudes I'm talking about have wandering eyes while I'm talking to them, wearing a turtleneck and wool pants. I don't understand it, these individuals come from all walks of life and some are quite attractive and popular with a very active, opposite-sex, social calendar; so what is it? Were these creatures absent from life's sociology course the day the instructor taught that women are no longer simple physical objects and that women have been actively contributing to society well beyond a sexual capacity for virtually a century now?

In spite of these obvious elements, such men seem biologically driven to focus in on a woman's physique, even in the midst of a totally inappropriate and unrelated atmosphere. They behave as though they've just been released from a 15 year, abstinence-enforced prison sentence...everyday! I don't get it, and as a professional female; I find it highly annoying.

There are times when, dressed for a girls-night-out occasion; it's apparent I'm receptive to such attention, but Monday-Friday; when I'm at work or the gym or walking my dog - it's NOT okay to oo-gle. It's distracting, offensive, and vulgar.

There are thousands of other men around me who seem to have intuitively figured out when oo-gling is okay and when it's not (or they just fake it well) - what's with these stragglers?

The GridView's GREAT From Up Here

I recently found myself frolicking in the land of .NET 2.0 SqlDataSources and editable GridViews. After reading numerous excerpts touting the flexibility and ease with which web developers can now achieve virtually Excel-like interfaces between users and their data, I was stoked to try it all out.

In retrospect, I will certainly award snaps to those MS peepz for their notable effort towards predicting and facilitating the common-place task of giving web application users discriminating access to database stored information. I can only imagine the daunting task of attempting to allow for all derivations of developers' preferences (Lord knows we're opinionated if nothing else) while at the same time maintaining a minimal level of Integrated Development Environment complexity in order to achieve some element of intuition.

That said, I had a bit of trouble getting my (basic) editable GridView to work utilizing VS's all-encompassing, plug 'n play, SqlDataSource functionality. The predominant factor in my troubles were the subtle differences with which VS handles defining one's SqlDataSource select/update functions via referencing stored procedures versus defining them with embedding SQL statements directly within Visual Studio's SqlDataSource configuration wizard.

I'm happy to report that after a good night's sleep and some professional help, however, I worked my way through the cryptic behavior and resolved all the issues. Here are the 'GOTCHAS' I encountered, in the hopes of alleviating [some of] a fellow developer's trauma while exploring the wide world of editable GridView's.

Behavior #1: No errors being generated and no exceptions being thrown, but the GridView's update function just doesn't do anything. I encountered this problem when the condition within my Update stored procedure was not being met [WHERE MAIN_ID = @MAIN_ID]. Unfortunately the reason(s) the condition was failing weren't obvious.

• Reason #1: As stupid as I feel admitting this, I'm going to do it for the sake of others who could be making a similar error. I wasn't including the MAIN_ID field within my GridView's select query. VS did not generate any type of error in spite of the fact that I was declaring a parameter named @MAIN_ID within my Update function that was not included as part of my GridView's select query, but maybe that's so they can allow for extraneous GridView column additions. At any rate, my 'where' condition failed in this case (obviously!) since it likely had a value of 'NULL' for the @MAIN_ID input parameter value.
• Reason #2: If you're referencing a stored procedure for your GridView's select query, you're likely missing the necessary DataKeyNames attribute value within your GridView element. At a minimum, this attribute needs to hold the name of the field(s) you're using within the where clause of your update statement (in my case, I need DataKeyNames="MAIN_ID"). From what I can tell, VS will auto-populate this attribute if you're embedding the SQL directly within its SqlDataSource wizard with the names of any primary key columns it encounters, but no such auto-population will occur, nor will any errors/exceptions be generated when you're referencing your own stored procedure.

Behavior #2: A 'Procedure or function [your procedure's name here] has too many arguments specified.' exception gets thrown when you attempt to update a record within the Gridview.

• Another dissimilar behavior characteristic between using embedding SQL versus a referenced stored procedure is VS's ability to automatically determine the fields that should be included as parameters within the GridView's update statement. When using embedded SQL, the update parameters will be automatically limited to those elements included within your SqlDataSource's element regardless of the number of BoundFields you have listed within your GridView. However, when referencing a stored procedure every BoundField that does not contain a ReadOnly attribute value of 'True' (and BTW it's default value is 'False') will be included as a parameter and sent to your stored procedure REGARDLESS of what you have listed as . This seems highly un-intuitive to me, too, but it's an easy fix once you know that's what's going on. You can either change each of the BoundFields that you don't want included as update parameters to have a ReadOnly attribute value of 'true' or you can go ahead an include their column names as input parameters within your stored procedure (@CURRENT_STATUS_DESCRIPTION) and just do nothing with them.

As a sidenote, here are a couple of incorrect/outdated solutions I encountered on other forums and wasted time pursuing:

• Solution #1: The = comparison issue. One forum claimed that if you were including nullable columns within your GridView and attempted to update a column with a current value of NULL, the GridView's update procedure would attempt a = comparison, which would return false and halt the execution. I found no such behavior in my .NET 2.0 Framework and SQL Server 2000 configuration.
• Solution #2: Anything to do with the value contained within SqlDataSource's ConflictDetection attribute. After wasting time on this one, I wound up using the default value (easily achievable by just omitting the attribute altogether) and everything's working just fine.
• Solution #3: Anything to do with the value contained within SqlDataSource's OldValuesParameterFormatString attribute. [See solution #2].

Other than that, Mrs. Lincoln...how was the play?