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?

Sleep Tight

The ASC Stinger; Fast, strong, gorgeous, and built on the 2005 GTO chasse...I think I'm in love.

The ASC Stinger car has inspired me to make my car into even more of a sleeper than it already is. It used to bother me; the lack of reverence and awareness paid to my car in spite of its impressive, corvette-engine performance specs. Unlike its much sexier, inferior performing, counterparts, only the occasional, true motor-heads stop to take another look at my vehicle, or listen for the throaty growl of 400 horses when I roll by. So I've come to a conclusion; why fight it?

As such, my automobile will be undergoing a few subtle, yet effective exterior modifications to further conceal its origins and remarkable performance capabilities - making it an even more severe sleeper:

A JHP lip spoiler replacement
18" wheels (something with a thick 5 spoke chrome look)
A Skip Shift Disabler
All-Around Badge Removal
A Gauge Pod


Christmas Wish List:
Short Shifter (Not sure what they were thinking when they gave the GTO a shift throw that's a mile long. This little device would probably shave half a second off my quarter mile time. ^_^)