"Size without Comments" inconsistent

I recently noticed that the sizes displayed are different for the same trigger between the Triggers sections under the object and the Triggers section under Develop.  For instance for Task triggers they appear to be bigger when listed under Task.  Not a major issue but kind of annoying to have that inconsistency...  By the way this is a CS12 sandbox org.

Using image resources from Salesforce

http://forcecrazy.blogspot.com/2010/08/using-image-function-in-formula-fields.html

It's in a sense a form of reverse engineering, which carries the risk of SFDC changing it with no obligation to notify you or support your solution in any fashion.  It's unlikely to happen, but keep in mind of the possibility and weigh it against your cost of modifying the solution when needed.

addMonths(): date manipulation in Apex

If today is March 31st, what is the date 6 months from now?  Honestly I wasn't sure what the answer should be. For Force.com Apex, it thinks that the date should be September the 30th.

Anonymous execution:

system.debug(date.valueof('2012-03-31').addmonths(6));

Result:

11:46:30.035 (35261000)|USER_DEBUG|[7]|DEBUG|2012-09-30 00:00:00

 

a Field ID for Case (and other objects)

Poll (for the Force.com guys):  Do you have a solution in production that uses a field Id in a custom URL to pre-populate page fields?

I suspect the percentage would be pretty high.  It's an easy and effective solution, but, it's a method frowned upon by SFDC (see a SFDC Product Manager, mtbclimber's response to this Idea). 

Liked or not by SFDC, I just think people will continue to use it and they will thus feel obliged to support it.  This is my favorite page to get the Field IDs for standard fields (custom fields are much easier - no need for a reference list):
http://phollaio.tumblr.com/post/22058016777/how-to-obtain-a-field-id
http://theblogreaders.com/salesforce-standard-object-field-ids/#.V7xHmJgrKUk
I recently notice the list is missing one field from Case: Account.  Even though it's automatically set when you select the Contact, you can use it independently if needed.  So here's the Id to set it if you desire:

CASE Field	Field Type	Field ID
Account	ID	cas4_lkid
	Text	cas4_lkold

Update:
Info for the Parent Campaign field on Campaign.
Field                   Field Type   Field ID
Parent Campaign  ID                 Parent_lkid
                            Text               Parent

Criteria based sharing rule with Force.com ANT tool - The Guide is wrong!

The Force.com Migration Tool Guide says to use criteriaBasedRules as the name (see page snapshot below).  Well, that'd just give you this error: Unknown entity:criteriaBasedRules



The correct name/syntax would be like this:

    <types>
        <members>Share_to_BIT</members>
        <name>CaseCriteriaBasedSharingRule</name>
    </types>

That's for case and I'd imagine for others (Campaign, etc.) just use the appropriate prefix.

Reset Nexus 7

What can you do when your beloved N7 is out cold?  This was what happened to me today (Where's My Water was the culprit).  Nothing was responsive on the screen including all the soft buttons.  I tried press and hold Power to no avail, which I later found out needed to be to 10 seconds - that's right, it has to be that long instead of the usual 3 to 5 secs.  Seriously, it's not until the 9th Mississippi for the screen to go dark.:-)

Variable binding in Apex for dynamic SOQL/SOSL

There are two related topics in the Apex Developer's Guide: Dynamic SOQL, and Using Apex Variables in SOQL and SOSL Queries, but neither provides an example of combining the two.  Well they do combine and work fine, so here's a simple example if anyone is interested:

Id [] ids=new Id []{'500e0000000gev6','500e0000000gevB'};

string q='select id, subject from case where id in ';

case [] cs=database.query(q+' :ids');

 

This is of course pretty useless, but sometimes you need truly dynamic query with a collection of parameters, the combination would be very handy.  A recent code example I had:

    public static void create_recurrences(List<Id> templates){
          ... ...
        Map<String, Schema.SObjectField> M = Schema.SObjectType.Case.fields.getMap();
        string q='SELECT Id ';
        for (Schema.Sobjectfield f : M.values()){
            if (f.getDescribe().isUpdateable()){
                q+=', '+f.getDescribe().getName();
            }
        }
        q+=' FROM Case WHERE Id in ';
        for (Case c : Database.query(q+' :templates ')){

               ... ...

I'd imagine if you're doing any kind of partner apps, this type of thing could get used a lot.

The "sandbox" record ID marker

When a sandbox org is created from a Salesforce.com production org, all record IDs are preserved.  When you create a new record in that sandbox, the ID format is slightly different from the production ones.  The prefix is of course the same, as a few things depend on it, but the first character after the prefix will be different.  In a production org that character might be 3, for instance, an account's ID is 0013000000VBUP3.  In a sandbox it is not going to be 3, so it would be something like 001V0000003iXtZ.  In fact it seemed to be V all the time in the past (I imagined that stands for "virtual").

Using a "sandbox" designator character in ID probably helps the system to avoid ID collision more easily.  Interestingly the newest sandbox I created seems to have a different designator - e.  I don't know if that's a new thing - it's certainly the first time I noticed - which may have come with this new wave of added infrastructure investment, including this new CS15 sandbox instance (coming off a new na13 production instance).