Apex Code Development You need to sign in to do that
Don't have an account?
benjasik Sforce 5.0 issues thread
We'll be using this thread to discuss any possible regressions/issues with the 5.0 release.
- One thing not mentioned in the release notes, but a change that was made: All IDs should now be returned as 18-character IDs. This was previously not the case, which was a bug as the WSDL defined ID to be 18 characters. If this has affected your integration, please post. Also, if you are doing any special handling for ID fields because their not 18-character you should post this info as well.
Note that we will be rolling back this behavior for 4.0 and below, and 5.0 will always return 18 character ids. This is only the case for organization_id on the getUserInfo call. Rolled back on 11/15 for 4.0 and below apis
- Running a query that returns more than batchSize records on OpportunityLineItem is failing. Fixed on 11/15
- Address Label changes are causing problems for customers using Data Junction and XML/RPC. Please log a case if this issue is affecting you. These labels will be left with their new values.
- The Web Integration Link URL for the API servers now returns the API pool. For example, this merge field: {!API_Enterprise_Server_URL_25} now returns na1-api.salesforce.com and not na1.salesforce.com. If you have a WIL that needs to return back to the detail page when it's done, you should use the detail page merge field. For example, on Opportunity this would be: {!Opportunity_Link}.
There are also some scontrols that have stopped working because security settings only allows code to talk with the originating server. We are reverting this change, and a short-term fix is to hardcode the originating server url, such as na1.salesforce.com
Patched 11/18
- Calling retrieve when setting the batchSize header and the number of elements retrieved is larger than batchSize is causing unexpected_error faults for some entities. Patched on 11/18. However, there is still an issue if you are selecting a long binary column on an entity such as Attachment or Document. Patch pending
- Retrieve used to always return id. Now it is only returning id if you request it. Short term workaround: adding id to your select list. Patched 11/18
- Querying user on firstName or lastName will not return any rows. Patch release on 11/16 to api servers, on 11/18 to all servers.
- A SOSL call on User that selects division will return an error. Example: FIND {Steve} RETURNING User(Division, Email). Workaround is to not select divison. Patched on 11/18
- New fields: SystemModstamp was added to AssignmentRule, and SortOrder was added to OpportunityLineItem. New fields can appear in older versions of the API.
- The WSDL generation page now respects field level security. Note that you must be an admin to even view this page, so you can always make fields hidden via FLS visibile. No change will be made here
- Dates are now validated such that the year is between 1700 and 4000. This will be rolled back for 4.0 and below, and kept for 5.0. If you are requesting a date field using .NET, and the field is null, .NET turns that into 1/1/1. When sent back up, this is causing problems. This does not seem to be a problem for any other client. Patched on 11/18
Message Edited by benjasik on 11-18-2004 07:45 PM
I just noticed (the hard way
) that the UserRole object now has a LastModifiedById. I did not see this mentioned in the release notes or anywhere else.
Have LastModifiedById or CreatedById been added to any other object?
Did I overlook a mention of these new fields?
I attempted to compare WSDL files, but large numbers of minor changes prevented a good comparison. For instance, vs. . Perhaps you have a good comparison you could post?
SystemModstamp was added to AssignmentRule, and SortOrder was added to OpportunityLineItem
I don't have a problem with fields being added, I have a problem that this is the first I've heard of it!
BTW, as to your decisions going forward, please consider carefully the addition of Reference fields. They have an impact on the relationships between objects. In particular, my code broke because I've got a User who is in a UserRole which was last modified by this same User! I used to only have that problem with Profile records.
Message Edited by John Saunders on 11-14-2004 01:51 PM
A big THANK YOU on that last one... At the same time, however, is there a changelog / detailed relase note document (like for the main UI - some 42 pages long) with these changes? These weren't on the technote.
I parsed the WSDL a bit and ordered it a bit to diff it... The obvious changes (excluding the ones mentioned in the TechNote and Earlier in this thread) include:
There were also several fields that were dropped from my 5.0 WSDL (on my EE account):
It appears as though someone/something changed the field-level security to disable those fields. I'm now looking into this and will report back when I have more.
Profile did undergo some major changes, but only in 5.0. We are maintaining backwards compatability in 4.0. This is due to the fact that most major entities now have Create, Update, Delete and Read permissions, and many of the permissions you no longer see are controlled by those. These are the same permissions Custom Objects have had for some time.
The other new fields you mention are correct.
Note that other people may have different results, based on their field-level security settings (some customers will not see any of these fields removed. Aside from new fields (which is something we have always added), but it sounds like this may cause problems for some people, APIs that are 4.0 and below should remain backwards compatible. If you're noticing anything else, please post.
Benji,
I'm not sure what you're saying here. Are you saying that the previous APIs returned 18 always, and now you're changing that? What exactly is getting rolled back?
----------------
One thing not mentioned in the release notes, but a change that was made: All IDs should now be returned as 18-character IDs. This was previously not the case, which was a bug as the WSDL defined ID to be 18 characters. If this has affected your integration, please post. Also, if you are doing any special handling for ID fields because their not 18-character you should post this info as well.
Note that we will be rolling back this behavior for 4.0 and below, and 5.0 will always return 18 character ids. This is only the case for organization_id on the getUserInfo call. Rolled back on 11/15 for 4.0 and below apis
So, 4.0 and below, organization_id on getUserInfo returns 15-char id, 5.0 and up, 18-char. All other ids returned will be 18-characters.
Note also that an 18-char id can easily be converted into a 15-char id by dropping the last 3 characters. The 18-char id is a case-insensitive id, as some of our clients are written on case-insensitive environments.
Think I have a quick document errata you may want to add to your list Benji. Date/Time fields now appear to have more strick checking on their values. Back in Summer 04 when I ran our import into our EE org, some activity dates came through as-is -- corrupted by the old system. So we have some dates in the system that are 10-10-0004.
I'm going to be going through those and attempting to fix them, but I do know if you try to update any other part of that record with an invalid date/time the api server will throw an exception on the record. Also the record is not visible in the UI (and may or may not have been before - I don't know). Since the records are all historical in nature it's not a high priority fix for us. If we have problems making the corrections via the API I'll update the post.
Just a quick note:
Wanted to throw Benji some public kudos -- He's been very much on top of both the public posts/problems as well as very approachable and proactive privately as well.
Good Job Benji and Thanks!!!
In the previous releases it seemed to be set at 2 hours but now I see it timing out at 1 hour.
Does the front end setting of the session timeout have any control over the backend API sessions?
Thanks.
Jon