function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
gargamelgargamel 

Missing entity type information. sObject requires a separate 'type' field be sent. at C:\dev\adm\gus\gus\main\p4\gus.pl line 793

Here is part of the subroutine:

        my $self       = shift;
        my $changelist = shift;
        my $sObject_type = 'ADM_Work__c';

        if( $self->{_p4status} eq $GUS::OPEN_ONCE ) {

            print "\n\n ----------------------------------------------------------------------\n";
            print "$sObject_type, id => " . $self->{_id} . ", Perforce_Status__c => $GUS::NONE)";
            print "\n\n ----------------------------------------------------------------------\n";

            my $result = $self->{_sfdc}->update(type => $sObject_type, id => $self->{_id}, Perforce_Status__c => $GUS::NONE);
           
            if ($result->valueof("//updateResponse/result/success") ne 'true') {
                # log problem here
                print "unable to update p4 status";
            } else {
                $self->{_p4status} = $GUS::NONE;
            }
       
Here is the output:
 ----------------------------------------------------------------------
ADM_Work__c, id => a0HT0000000KIZbMAO, Perforce_Status__c => --None--)

 ----------------------------------------------------------------------

Type looks to be getting set from the print statement output??
RatherGeekyRatherGeeky

Did you ever get this resolved?

 

I'm getting the same error and I don't know why.

jrosejrose

I'm with J Baze. I can run the perl script containing this update on my development machine but it doesn't work when I place it on a job server.

 

                    my $UI_Id =  $field->{'Id'}."\n";
                    my $objType = "Custom_Object__c";
                    
                    #my $UI_Id = substr($UI_Id,0,-3);
                        
                    print $UI_Id."\t";
                    print $field->{'SiteName__c'}."\n";

                    my %update;

                    $update{'Agent_Indexed_On_Date__c'}='2009-09-11';
                    $update{'id'}=$UI_Id;

                    WWW::Salesforce::Constants->register_type($objType,$update{'Agent_Indexed_On_Date__c'},'xsd:date');

                    my $index_date_update_result = $sforce->update('type'=>$objType,%update);

                    

jrosejrose

My linux team solved the issue here. The SOAP-Lite module (and it's dependencies) needed to be updated.

 

Can anyone else confirm?

 

-Joe

LeonardLeonard
I'm having the same issue in Flex.
richardc_rsvprichardc_rsvp

I am seeing the same message from our app using Apex Ajax. One customer got it and it went away on it's own. Now another customer has it. I have opened a case (03629985) in the Partner Portal. No resolution, yet.

richardc_rsvprichardc_rsvp

I have found that I only see this problem from Ajax when the Chrome browser is used. IE did not exhibit the problem.

dcc2904dcc2904

I second the comment that this issue only appears with the Chrome browser.  I tried Firefox and it worked fine too.

 

 

Cheers,

 

DrawloopSupportDrawloopSupport

Just so everyone knows, it seems like this is still an issue in Chrome (worked in Firefox).

forcefanatic1forcefanatic1
I believe the ordering of setting the type is important. sObject.setType() should be the first statement after the object is initiatlezed, before any setField() methods are called. See this discussion - https://developer.salesforce.com/forums?id=906F00000008jJcIAI