More of an FYI post as I think I have a workaround for now, but my Force.com IDE (version 28.0) was having an issue with workflows all of a sudden.  This worked fine previously.  When selecting Workflow Field Updates, the package would appear empty.  The package.xml would include the field updates in the list, but there would be no workflow folder under Src.  It appears as though my IDE is pulling down the package as version 15.0, which presumably doesn't have workflow field update support (workflow rules still pulled down okay).  I update the package.xml version to = 28.0 and the workflow rules now appear correctly.  No idea how this versioning change is happening.  I've used this IDE for a while and had not previous issues until this month.  I've tried to go to the latest Eclipse plugin, but I have apparent JRE issues where the select component screen does not render correctly or is blank - no clue how to resolve that.

We recently refreshed a sandbox and now when trying to pull down classes into the IDE, we are unable to.  The classes folder is empty.  Other sandboxes seem fine.  There are definitely classes in there.

Any ideas?

 

 

Some of our custom settings are giving a NAME TOO LONG error when we update them. Which means if we want to change the values, we have to update the code to use a shorter name!

 

Happened when Winter' 13 hit the sandboxes.  Seems to have gone from a limit of 40 to 33... imagine if they did that for all object fields!  This release has really been disruptive so far. 

 

 

I constantly run into an issue in the Force.com IDE when pulling down custom fields on standard objects (usually paired with custom objects as well).  Say I pull down 2 custom fields on the Account object and 2 complete custom objects into a new package with the Force.com IDE...

 

If I go back into the package and "Add/Remove Metadata Components", then I see that the contents of the package are correct in the list view, but once I select "Add/Remove" from the content view page, then the 2 Account fields are unchecked. This happens intermittently and is really annoying as it is easier to not notice with larger packages and you end up removing necessary fields.  It becomes a vicious cycle sometimes.  It seems if I cancel adding new metadata components and close Eclipse, then reopen and re-add, everything works as expected. 

 

Anyone else hit this?

After the Winter '12 release, we receive the following error (the exact error numbers vary) for EVERY test method in our Production instance when pushing via the Force.com IDE:

 

"Internal Salesforce Error: 57854184-2273 (-475640446) (-475640446)"

 

 

Anyone else experiencing this?   When we deploy change sets or run all tests via the UI, this error does not happen.  It occurs for both Validations and Deployments with the IDE.  It was working fine last week, then Winter '12 hit.

 

And yes, we have a ticket pending with support.  I would just like to know if this is widespread.  Thanks!

 

 

Is it possible to mass change the objects settings for a profile instead of doing it one by one in Profile Overview / Object Settings?

More of an FYI post as I think I have a workaround for now, but my Force.com IDE (version 28.0) was having an issue with workflows all of a sudden.  This worked fine previously.  When selecting Workflow Field Updates, the package would appear empty.  The package.xml would include the field updates in the list, but there would be no workflow folder under Src.  It appears as though my IDE is pulling down the package as version 15.0, which presumably doesn't have workflow field update support (workflow rules still pulled down okay).  I update the package.xml version to = 28.0 and the workflow rules now appear correctly.  No idea how this versioning change is happening.  I've used this IDE for a while and had not previous issues until this month.  I've tried to go to the latest Eclipse plugin, but I have apparent JRE issues where the select component screen does not render correctly or is blank - no clue how to resolve that.

It seems that the new Summer'13 update enforces you to work with 18 character ID's always. For example, this happens in apex:

 

Id Id15 = string.valueOf(Id18).substring(0,15);
System.AssertEquals (Id15,Id18);

 

Pre-Summer that assertion fails, as Id15 is the 15 character Id and Id18 is the 18 character Id.
In our custom code many times we use Custom Setting and Custom Labels to avoid hardcoding recordtypes, profiles and other "constant" values. We usually worked with 15 character Ids as Salesforce (SOQL) sometimes returns 15 and other times returns 18 character Ids.

 

Now it seems the ID type always returns 18 character, if you do something like this the assertion is true:

 

Id Id15 = '012200000005byN';
System.AssertEquals (Id15,'012200000005byNAAQ');

 

As this is happening now with the Summer'13 but not happening before with Spring'13, this invalidates many coding.

We found this problem as Salesforce triggered a deep system error like this Salesforce System Error: 1619326252-34083 (1564369920) (1564369920) trying to compare a SelectOption loaded with record types with a Custom Settings String Id Stored.

 

This is a really weird annoyance. You can take a workaround working always with ID type instead of storing Ids into Strings, and always working with 18 character Ids, wether you hardcode Ids into apex and formulas (not a good approach) or you use custom setting and labels to store the ids.

 

Hope this helps... I lost all morning trying to figure out this.

Some of our custom settings are giving a NAME TOO LONG error when we update them. Which means if we want to change the values, we have to update the code to use a shorter name!

 

Happened when Winter' 13 hit the sandboxes.  Seems to have gone from a limit of 40 to 33... imagine if they did that for all object fields!  This release has really been disruptive so far. 

 

 

Are deployments are starting to take an exceedingly long amount of time.  We have about 600 apex tests and it's now taking hours to run them.  Since we need to do several validations to flush out any deployment issues, it's really putting a damper on our release cycle.

 

Anyone else have this problem?

 

 

What I've noticed looking at some logs of tests is a huge amount of time is spent inserting test data.  I know it's best practice to insert data specifically for testing rather than rely on data alredy there.  But, it is take many seconds just to insert and Account.  More than half of that is territory processing.

 

I don't want to have to rewrite all our tests to work of data already in the database but I want to come up with some way to speed up the validation.

 

 

Removing of null to set gives an error "System.NullPointerException:Argument 1 cannot be null"

 

Ex.

 

acctid.remove(null); <------ This will give error in winter 13 but not in summer 12

 

Please help me to understand what is wrong i maybe missing something here. Thanks

I constantly run into an issue in the Force.com IDE when pulling down custom fields on standard objects (usually paired with custom objects as well).  Say I pull down 2 custom fields on the Account object and 2 complete custom objects into a new package with the Force.com IDE...

 

If I go back into the package and "Add/Remove Metadata Components", then I see that the contents of the package are correct in the list view, but once I select "Add/Remove" from the content view page, then the 2 Account fields are unchecked. This happens intermittently and is really annoying as it is easier to not notice with larger packages and you end up removing necessary fields.  It becomes a vicious cycle sometimes.  It seems if I cancel adding new metadata components and close Eclipse, then reopen and re-add, everything works as expected. 

 

Anyone else hit this?

I recently upgraded my Force.com IDE (and all projects) to the Winter '12 release. Since upgrading, I've been observing that when I attempt to run unit tests against an Apex class, it often takes a very long time to execute. Even relatively simple tests sometimes take a minute or two to complete. The time doesn't seem to be spent during test execution, but rather during the "preparing results..." phase (based on the progress indicator in the IDE). Reducing the log level doesn't seem to have any impact one way or the other. I've also seen it simply get stuck in the "preparing results..." phase to the point where I had to kill the Eclipse process. Anyone else seeing this?

Does anyone know if there is a new release coming up for IDE? Are there alternatives for force.com ide? 

This just started today (9/26/2011) and won't let me save the file to force.com. The file is a long existing apex class. Only making some minor changes.

 

 

Save error: Unable to perform save on all files:

 

com.salesforce.ide.api.metadata.types.Metadata$JaxbAccessorF_fullName cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor

 

I deleted the whole project and re-added it. I was able to get everything back, then tried to make changes again. Same error. I tried to refresh my file from the ORG and received a pop up with the same error.

 

 

I've got a workflow that will send out an email after 1 hour if a particular set of conditions are met. To simplify, let's say the workflow formula is

 

fieldA__C==1 && ISPICKVAL(fieldB__c,"Location B")

 

I can successfully get the email sent after an hour when I set fieldA__C to 1 and fieldB__c to "Location B". What I want, though, is for that email to NOT go out if the workflow formula evaluates to false after the email is already been queued. That is, the workflow evaluates to true, and queues up the email. Then I change, say, fieldA__c to 2. I was under the impression, from reading the help docs, that this would dequeue the pending email. Real-life experiments seem to indicate otherwise, though, as I still get the email.

 

Any input would be appreciated.

 

BTW - Here's the relevant section from the help docs:

"Time-dependent actions remain in the workflow queue only as long as the workflow rule criteria are still valid. If a record no longer matches the rule criteria, Salesforce removes the time-dependent actions queued for that record. "

 

https://login.salesforce.com/help/doc/en/workflow_time_action_considerations.htm

Hi All,

 

I just logged this issue with SF.com support.  However, I figured I'd post the issue to the forum as well, to see which venue yields a better response. :)

 

---

 

I have a single Custom Field ("Handles_Title__c" ) on a Custom Object ("Purchase__c" ) that I would like to deploy via the Force.com IDE. However, I am getting an error "Must specify a non-empty label for the CustomObject" when I try to deploy this field.


Steps for Reproduction:

Preconditions:

I have two sandboxes, "greg" and "stage". Both sandboxes have acustom object called "Purchase__c". However, the Purchase__c object onthe "greg" sandbox has an additional field called "Handles_Title__c"that does not exist in "stage".

Steps:

1) In eclipse, go to File -> New -> Force.com Project. Create a new project pointing to the "greg" sandbox.

2) On the "Choose Initial Project Components" page, choose the"Selected metadata components" radio button, and click the "Choose..."button.

3) On the "Choose Metadata Components" page:
3.a) Expand the "objects - custom list"
3.b) Expand the "Purchase__c" list
3.c) Expand the "customfield" list
3.d) Check the box next to "Handles_Title__c"
3.e) Click the "Ok" button

4) Back on the "Choose Initial Project Contents" page, click the "Finish" button.

5) Right click the "src" folder in the newly created project. Select Force.com -> Deploy to server...

6) Enter login credentials for the "stage" sandbox, click "Next".

7) On the "Archive Options" screen, uncheck both "archive" checkboxes, click "Next".

8) On the "Deployment Plan" screen, check the "Overwrite" box for "Purchase__c". Click the "Next" button.  


Expected Results:

The custom field "Handles_Title__c" should be created in the stage sandbox.


Actual Results:

Deployment fails with the error: "Must specify a non-empty label for the CustomObject"