You need to sign in to do that
Don't have an account?
Maxa
Summer 09 APEX code failures
has anybody had any problems with their APEX code with summer 09, mine started workgin in really strange way not like it designed to, it completely runs away in a different direction
Does changing your logic make any difference eg.
Old:
List<User> userlist = [select id, name from User where isactive=true and id in(Select userOrGroupId from GroupMember where Group.name = :groupName)ORDER BY id];New (something like):
List<Id> members = new List<Id>();for(GroupMember gm : [Select userOrGroupId from GroupMember where Group.name = :groupName])members.add(gm.userOrGroupId);List<User> userlist = [select id, name from User where isactive=true and id in :members ORDER BY id];
I know this doesn't take from the fact that weirdness is happening but it may keep your code working for longer!
(Could perhaps getting all users back and checking id in the result from the GroupMember results.... )
It's an odd error you have and I'm interested in the response from SFDC.
I shall follow and see what happens.
Good luck.
R.
All Answers
Hi maxa,
Not quite sure if the summer '09 can be blamed for code 'running a way in a different direction'.
There was a few teething troubles with packaging and using apex: form tags, which are all now fixed, everything seems fine. We have 20+ development and live sites and all seem to be running ok.
Do you have an example of your problem?
R.
This bit of apex used to work fine, to display the list of account team members, fetched from the accountId on a case, and allow users to transfer ownership to just those members. In our case only one accountTeam is populated, with 28 members. And code worked great.
Recently the pick list is populated with virtually every user in the SF instance. And they are not members of the original 28. Something like 84 users show up.
Is this is bug in Apex 09? I have no other changes made to the system to account for such odd behavior.
public class AccountTeamCaseTransferExt {
private final Case c;
String teamMember;
public AccountTeamCaseTransferExt(ApexPages.StandardController stdController) {
this.c = [SELECT Id, AccountID, OwnerId FROM Case WHERE Id = : stdController.getID()];
}
public PageReference transfer()
{
if (this.teamMember != NULL)
{
c.OwnerId = this.teamMember;
update c;
}
PageReference pageRef = new PageReference('/' + c.Id);
pageRef.setRedirect(true);
return pageRef;
}
public List<selectOption> getTeamMembers()
{
List<selectOption> options = new List<selectOption>();
options.Add(new selectOption('', '-- None --'));
if (c.AccountId != NULL) {
for (User u : [SELECT Id, Name FROM User WHERE Id IN ( SELECT UserId FROM AccountTeamMember WHERE AccountId = : c.AccountId) ORDER BY Name ASC] ) {
options.Add(new selectOption(u.Id, u.Name));
}
}
return options;
}
public String getTeamMember()
{
return this.teamMember;
}
public void setTeamMember(String s)
{
this.teamMember = s;
}
}
this is exactly my issue, it has ben escalated to their R&D, log a case with them as well.
there is a work around i found out if you edit some comments then save it works again untill midnight so youahve to do thsi every day kinda lame but no definite fix yet
What seems very odd to me is the fact the identical query run from C# produces expected number of rows. Where as the query in the APEX extension produces these odd results (more rows than expected). Maybe it has something to do with OOSQL, caching of a compiled query or some such. Very odd indeed.
How long has your case been open?
And by what means is the result set limited to a certain group of users? A garden variety where clause... "FROM User WHERE IsActive = true" or something using a join as is in my case " FROM User WHERE Id in (SELECT AccountId FROM AccountTeamMember WHERE AccountId = 'someidhere')".
The common thread here seems to be the User table. If your answer is JOIN then think we might be on to something. Have a meeting with our sales rep and someone from developer team tomorrow. The more you provide the more I can relay then.
i use this
List<User> userlist =
[select id, name from User where isactive=true and id in(Select userOrGroupId from GroupMember where Group.name = :groupName)ORDER BY id];
This cannot be a coincidence. A SELECT from the User table with an IN sub clause in the WHERE returns the entire USER population.
The one odd thing still eating at me is why this query with the same type of IN sub clause and WHERE statement issued from C# against the SF web service works without a problem.
Must be something particular about how APEX code parses out, compiles down, caches, or something. Don't know. This is where "software you rent", not "software you own", or better "software that is open source"comes back to bite you in the ass. At the mercy of SF engineers at this point.
Thanks for the input. Will post tomorrow after I find out more.
what strange in my case my debug log does not retur correct data set, but code works
it's a kinda magic
Does changing your logic make any difference eg.
Old:
List<User> userlist = [select id, name from User where isactive=true and id in(Select userOrGroupId from GroupMember where Group.name = :groupName)ORDER BY id];New (something like):
List<Id> members = new List<Id>();for(GroupMember gm : [Select userOrGroupId from GroupMember where Group.name = :groupName])members.add(gm.userOrGroupId);List<User> userlist = [select id, name from User where isactive=true and id in :members ORDER BY id];
I know this doesn't take from the fact that weirdness is happening but it may keep your code working for longer!
(Could perhaps getting all users back and checking id in the result from the GroupMember results.... )
It's an odd error you have and I'm interested in the response from SFDC.
I shall follow and see what happens.
Good luck.
R.
That's an interesting idea. The IN clause of the WHERE statement still exists but is static. That is to say the contents of the IN will not be derived on the fly from another SELECT query. I cannot really test it because it only happens in production and I cannot 'play' there.
This all smacks of some sort of cache expiration type issue to me. Turn debugging on for me, or in the case of the other reporter update a comment, and presumably the APEX code and embedded queries recompiles and caches. Midnight passes by and the query in the IN statement appears to stop having a limiting effect, and the entire user population comes back.
Well the meeting went ok. Mind you the parties I was speaking with were not technical in nature so it was more of let me take down the details and help get this escalated type of thing.
Also logged a case with a very detailed explanation. But since we do not pay for premium support it may take a while to get a response. As soon as I hear back anything will post it here for those following the thread or experiencing the same.
Thanks Richie i try out new code today see if it works.
we do have premium support but it's been over 1 month for them and problems still not resolved.
i have told them about your case as well
Maxa -
My general case number is 02816035 if you want to let the premium support guys know. The only reason I mention it is I did a very nice write up with screenshots, code snippets and all. Sometimes a picture is worth a thousand words.
What if anything have you received in terms of feedback? Does SF even acknowledge this as a problem?
Richie -
Thanks for the idea. Have place the changes in Production and eagerly wait to see if it survives the gremlins that come out at night in the SF data center.
Old Code:
New Code: (bascically busting the SUB SELECT in to two queries, perhaps skirting the issue, will know tomorrow)
Ok query is still working today. So has something to do with having a SELECT X From User WHERE X.y in (SELECT something) syntax, using an ApexPage.StandardController extension class, only in production org.
For now we will run with the broken out aproach. SF team is working on trying to sort this out. Will post again as soon as more comes available.Thanks again Richie for the idea.
i'm triliang this new piece of code
List<GroupMember> groupMemberList = [Select userOrGroupId from GroupMember where Group.name = :groupName]; List<Id> userFilter = new List<Id>(); for (GroupMember gm : groupMemberList) userFilter.add(gm.userOrGroupId); List<User> userList = [select id, name from User where isactive=true and id in :userFilter ORDER BY id];
so far all working ok, my debug logs still show incorect data in them, if it's still good by mid week i move it to prod
code workgin for 2 days stright, thank god,
also got responce from Sf they identified it as major BUG with highest possible priority, i will let you know more when i hear from them, hopefully not long left
Code still working for me too...
All I got from SF is they were working to try and reproduce it, no word back from the QA department, no ETA on a fix, were closing the case, and would email when a fix was available.
Going to run on broken out queries and stay on broken out queries. No matter what patch, fix, release comes out of this.
Looking back at the forums there have been other times when a WHERE statement and User Table/Object went awry. So hopefully keeping the query as simple as possible minimizes the risk to such a thing happening in the future.
I'm rather pleased I found this thread.
I've been battling intermittent failures when running code of the form:
List<Custom_a__c> available=[select id, Name from Custom_a__c where id NOT IN (select Custom_a__c from A_to_B_Association__c where Custom_b__c IN :excludeIds ) ];
from a VisualForce controller (not an extension to standard controller though).
This will work fine in unit tests and on the pages, and then start to fail 30 minutes or so after deployment. Simply adding whitespace to the code and saving it (thus causing a redeploy) causes everything to start working again for a while, and then it fails again.
Has anyone heard an ETA for the fix?
No firm date provided. Just a range of "approximately two to three weeks".
Maxa and myself had the issue with the User table and a WHERE clause. This is a custom table I take it? Interesting. Did you try breaking the query apart?
If anybody reads this thread and thinks to themselves it sure would have been nice for SF to have told me about this bug after others reported back in June, or had a datababase available to search bugs following a major release (instead of the kindness of other users posting in the forum), please go vote for one of these...
http://ideas.salesforce.com/article/show/10093534/Developeraccessible_bug_database
http://ideas.salesforce.com/article/show/10095625/Known_Bug_email_alerts_for_Salesforce_Admins
Yes, this was a custom table. A number of them in fact.
We have the concept of diary events and various types of people, places and gear that can take part in the event. Once a person/place/fixed piece of gear is in an event, they are unavailable for its duration.
What I've been seeing is that it all works okay for a short while, and suddenly you can double book everything/everyone, until I add or remove a space character and redeploy it. Then it all works again for a while. This is on a dev org with several people working on it, which may account for why things go awry quickly.
I've broken up the person availability into single queries and the problem disappears completely.
Initially the availability of a person was checked using a single, very complex query. I thought originally it was the complexity that was the problem, but leaving a single subselect as described in my previous post goes bad too.
This issue has been fixed
Regards
Vivek Viswanathan