OMG! News Flash! SalesForce & TITSUP

HAHA  OH MY GOD!!!  Thanks goes out to Simon Sharwood and The Register for this article about a Salesforce Outage.

I simply MUST quote their update:
"One of Salesforce.com's European instances is enduring a lengthy un-planned PITSTOP incident – that's a Partial Inability To Support Totally Optimal Performance, a whit below our other status indicator of a Total Inability To Support Usual Performance or TITSUP."

HAHAHAHAH!!!!!  OH MY!!!!  TITSUP!!!!!  Never have I seen TITSUP and Salesforce on the same page before.  SO apropos, So right.  Thanks for the Thursday morning laugh!!!

**Disclaimer - I am not a fan of Salesforce, its abysmal development environment, its incomplete programming language APEX, its poorly thought out data structures and generally the whole Salesforce concept and system.

No NULL exception? What the Hell???

Just a little end of the day rant about one of my least favorite software packages, Salesforce.

If I do something like this, shouldn't there be a NULL exception?

integer bar = null;
integer foo = 1;
foo = bar + foo;


Absolutely.  And Salesforce's APEX language does indeed raise a NULL Exception.  However, a little different flavor of that will not raise an exception.

Say for example you have an integer field called bar__c in the standard Salesforce object Lead.  You have a piece of code that pulls that object's record into memory; like...

Lead wrkLead = [select ID, bar__c from lead where status='Lock' limit 1];


So, shouldn't there be a NULL exception here?

integer foo = 1;
foo = wrkLead.bar__c + foo;


Well, I would think so, but nope.  APEX just keeps on chugging.  Watch out for this one.  If your data field could ever be NULL, code for it!

Salesforce DML Limit... ARGH!

So there I am...  5AM on a Friday morning and I check a Salesforce task that should have run hours ago.   Thunk Thunk Thunk...  Is this thing ON???   Apparently not.

I run it manually and THWACK...  " Too many DML statements: 151"  After an hour of Googling and poking at the execution log the reason for this THWACK is obvious.  This Salesforce job was updating leads within a loop.  That's OK if the loop makes less than 150 iterations.  Shit...  This loop was trying to update thousands of leads.

The solution?  Pfff...  Rather than update each individual lead I need to change the code to place my updates in a List<Lead> and then, after the loop, updating the List.

What the Hell?!?!?  It worked in the dev Sandbox fine, just the way it was!  This is like taking a hot sports car out for a test drive, turning heads while driving 95 MPH down the freeway, feverishly buying the thing, then, once you are sitting in this testicular expression of your manhood, discovering it will only do 65MPH.

The specific lesson here is this...  When writing a Salesforce job (or anything for that matter) in APEX, DO NOT update table data within a loop.

Now leave me alone.  I gotta go rewrite this damned APEX job.

***Edited Oct 17, 2014 - 3PM***
Fine.  Just Effin Fine.  I found out why it worked in the sandbox.  Another programmer meant to refresh his leads in the sandbox while I was testing.  Guess what...  He refreshed my test data as well.  So, even if the 150 DML Limit works in the Sandbox, my testing wouldn't have caused a problem because there was only 50 leads in the damned Lead table!!!

New version is done and tested.  Guess I will get up before the dogs Monday and roll this out.