Hi,
       I am having a process of data load that has been tested in a sandbox and includes disabling of triggers as some of the steps. I now have my components deployed to production with the requisite test coverage. Now, when I am trying to disable triggers (by deploying the meta data xml file from eclipse with status=inactive) as part of my production data load, the test case run is getting triggered and failing since they require the triggers to be enabled (the test classes run fine when the triggers are enabled). This is causing the test coverage to be below the threshold value of 75% and the disabling of triggers is failing.
       Basically, the test classes and data load process are having conflicting requirements regarding the enabling / disabling of triggers. Please let me know how to get out of this catch 22 situation.

Best regards,
     Jaikish

Is there any infrastructure in the force.com platform to prevent dirty update? Consider the following chronological scenario :

1) User A views record R1and clicks edit
2) User B views record R1and clicks edit
3) User A modifies R1 and saves
4) User B modifies R1 and saves

    This sequence would overwrite changes made by User A. Is there a version management mechanism that would detect that save in step 4 will detect that the entity has been updated before and prevent it?

Hi,
       I am having a process of data load that has been tested in a sandbox and includes disabling of triggers as some of the steps. I now have my components deployed to production with the requisite test coverage. Now, when I am trying to disable triggers (by deploying the meta data xml file from eclipse with status=inactive) as part of my production data load, the test case run is getting triggered and failing since they require the triggers to be enabled (the test classes run fine when the triggers are enabled). This is causing the test coverage to be below the threshold value of 75% and the disabling of triggers is failing.
       Basically, the test classes and data load process are having conflicting requirements regarding the enabling / disabling of triggers. Please let me know how to get out of this catch 22 situation.

Best regards,
     Jaikish

Is there any infrastructure in the force.com platform to prevent dirty update? Consider the following chronological scenario :

1) User A views record R1and clicks edit
2) User B views record R1and clicks edit
3) User A modifies R1 and saves
4) User B modifies R1 and saves

    This sequence would overwrite changes made by User A. Is there a version management mechanism that would detect that save in step 4 will detect that the entity has been updated before and prevent it?

I'm trying to deploy (really transfer) a profile from one environment to another), but I'm getting a permissions error with the "Import  Personal Contacts" setting.

 

The problem is, this profile does not have that permission (Import Personal Contacts) granted, so I'm not understanding the complaint.  Does anyone know why?  I don't want these users to have Create/Edit Account permissions.

 

 

*** Deployment Log ***
Result: FAILED
Date: April 2, 2009 3:09:05 PM EDT

# Deployed From:
   Project name: xxxx-SFDC-Test
   Username: xxxxxx
   Endpoint: test.salesforce.com

# Deployed To:
   Username: xxxxxxx
   Endpoint: test.salesforce.com

# Deploy Results:
   Name:    profiles/FS Outsource Profile with Flex.profile
   Action:  NO ACTION
   Result:  FAILED
   Problem: Permission Import Personal Contacts depends on permission(s): Edit Account, Create Account

   Name:    package.xml
   Action:  UPDATED
   Result:  SUCCESS
   Problem: n/a

# Test Results:
   n/a