Apex Code Development You need to sign in to do that
Don't have an account?
SoCal Admin Bug or Interesting record/object instantiation of Unpopulated fields
How are unpopulated fields handled in the PHP/WSDL framework?
I'm querying all records in a custom object. The records with unpopulated fields return:
PHP Notice: Undefined property: SObject::$Project_Manager__c in /var/www/testing/test.php on line 25
It ends up with some records being read correctly, but others have 1 error message like the above for every field that is blank (or null).
In this case, it's not possible to check if a field (or property) is null, because the property is not "in the record"(or object) if it is null. This is like having variant records: If an object has 20 fields, then there are potentially 18 factorial layouts.
Are we supposed to check for the existence of a field property before we access the value? This doesn't make sense when the property is specified in the query string.
I just verifiied that - that is exactly how it is working. If I edit the SalesForce record and populate the field. The error goes away, but if I delete the value after that and re-submit, the error returns.
This appears to be a bug - the very least is incorrect error message. The error message should be: "NULL Value processising not supported" or something to that effect - not "Undefined Property".
Here are 3 records from the same object. Note the missing fields from 52 and 54.
[52] => SObject Object
(
[type] =>
[fields] =>
[Name] => Stonson Plaid
[Order_List__c] =>
[Salesman__c] => Harry
[Id] => a1D3433d0008dznMAA
)
[53] => SObject Object
(
[type] =>
[fields] =>
[Account_List__c] => 27628
[Account__c] => 003434343434338VhqIAF
[Job_Location__c] => 232323
[Location__c] => a10454343430L2nEIAS
[Name] => Ring Filler
[Order_List__c] => 1
[Salesman__c] => Jonman
[Id] => a1DE00000008bCvMAI
)
[54] => SObject Object
(
[type] =>
[fields] =>
[Name] => Bill Thompson
[Order_List__c] =>
[Salesman__c] => Harry
[Id] => a3DE00000008345MAI
)
Hi,
It seems there might be a problem a with your WSDL file. Please try using the partner WSDL file or regenerate a new enterprise WSDL file
>>partner is loosely typed, so it should be ok with queries containing all objects and fields, but enterprise is strongly typed, so it requires you regenerate it anytime you add new objects or fields.
Please try this and let me know if the error still persists
please check this link aswell:
http://boards.developerforce.com/t5/Perl-PHP-Python-Ruby-Development/Referencing-SObject-field-data/td-p/442683
Thanks for your help, but it doesn't seem like you clearly understand the issue that is occurring in this post.
#1: If you go to the link that you recommended that I check, you will notice that I was the author/initiator of that link. It is completely unrelated to this issue because: If you look carefully, you will notice that ALL of the record RESULTS listed in the post are *exactly* identical. There is one field being returned in that POST and I was having trouble accessing the one field in EVERY RECORD RESULT. i.e. EVERY record failed because I was using the same, incorrect object reference.
#2: Part A - If you look at the data I posted in this post, every record "result" contains a "different" number of fields. Even though my query requests 7 fields - not every RESULT object returns "7" fields' This is clearly evident in the data I posted in this post.
#2: Part B - If you read my post, you will find that the RECORDS that CONTAIN FIELD data have no problems with the syntax I use to access the data in the fields, while at the same time, the RECORDS that DO NOT contain the Field data, fail. Since I am using a LOOP to loop through the records, I am using the EXACT same FIELD SYNTAX for EVERY RECORD returned - and ONLY the records with NULL or UNSPECIFIED field data for THAT record FAILS.
PHP/SQL differs from this in that NULL fields are STILL problematic, however A NULL value is returned that can be tested for using something like: ($t = myobject(['Job List']) . "") or something to that effect, however this implementation ERRS because the object ['Job List'] has been EXCLUDED from the list of Properties in OBJECTS retrieved from the server - BUT ONLY IN records where the Field Value is NULL. In the other records, my syntax correctly returns ALL field values.
I think its not a bug this is working as designed
http://wiki.developerforce.com/page/PHP_Toolkit_20.0_FieldsToNull_Sample_%28Enterprise%29
let me investgate more...
I just received an email today - stating the the same thing and referencing the same unrelated post.
Please escalate this case. This issue is not being addressed.
The email I received today is the SAME email referring to a link to the SAME unrelated post.
A SELECT statement by design SELECTS fields to be DISPLAYED, PROCESSED or **ACCESSED** (**REFERENCED**).
The CURRENT SALESFORCE TOOLKIT VERSION RETURNS an error when the OBJECT RETURNED by the SELECT STATEMENT is accessed for a non-existent property. This Might be acceptable IF THE FIELD DIDN”T EXIST IN THE Table/Object. THIS IS NOT THE CASE. The current TOOLKIT can not even check for NULL because the PROPERTY SPECIFIED IN THE SELECT STATEMENT is NOT RETURNED IN THE OBJECT WHEN THE VALUE IS NULL.
This is a BUG.
Please READ CAREFULLY:
A Virus Scanner that fails to stop a virus is STILL WORKING AS DESIGNED.
AUTOMOBILES THAT ARE WORKING AS DESIGNED are REQUIRED BY LAW to be returned when RECALL NOTICES are SENT.
EQUIPMENT DESIGNED POORLY is still WORKING AS DESIGNED.
The issue is not that the Toolkit is NOT working as Designed. The Issue is that the Toolkit IS NOT DESIGNED PROPERLY.
HOW CAN I WRITE CODE TO ACCESS A PROPERTY THAT IS SPECIFIED IN A SELECT STATEMENT WHEN THE ENGINE:
1) DOES NOT RELIABLE RETURN THE PROPERTY (OR NULL VALUE)
THAT WAS SPECIFICALLY AND PROPERLY REQUESTED?
2) RETURNS AN ERROR WHEN THE PROPERTY IS REFERENCED FOR RANDOM RECORDS!!?!
Hi SoCal Admin,
What's happening here is that fields that may be null are optional (minOccurs="0") in SOAP terms and are not passed back in SOAP responses at all (you can see this by using print_r($mySforceConnection->getLastResponse()) after a query.)
The way that the underlying PHP SOAP extension works is that, since these fields are not in the data on the wire, they are not in the PHP representation; that are just not added to the object.
What you're seeing is the consequence of all this - the 'undefined property' error on line 25 of your test.php script. You are correct in that you cannot test for the field being null, since it doesn't exist, but you can use the PHP isset() function thus:
if (isset($response->records[$index]->Project_Manager__c)) { // Do something interesting with Project_Manager__c }Cheers,
Pat
Thanks Pat - I can see that - as I documented it in the initial post. The problem is that this adds *extensive* coding requirements to any SELECT statement.
So are you saying this is *not* an issue with the PHP ToolKit, but rather an effect of the way PHP/SOAP in general works?
Is it possible to FORCE all fields to be returned (as empty string if necessary). This would be client-only processing (if implemented efficiently.)
I'm curious to find out if this is truly the case as it adds extensive overhead (more as additional fields are listed in the SELECT statement):
For *every* field listed in the select statement that is null:
1) a conditional test is required prior to *any* processing of that field
2) an additional, wasted assignment is required to process the data
Instead of this:
print $response->records[0]->field1
This is required:
if (isset(print $response->records[0]->field1)) {
print print $response->records[0]->field1;
} else {
print "";
}
If you use the partner API rather than the enterprise API, it will return a field in the response for each field selected.