• Limes
  • NEWBIE
  • 15 Points
  • Member since 2010
  • Software Developer
  • Interlochen Center for the Arts

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 1
    Questions
  • 4
    Replies

I am running the Lexi Data Loader on a Mac.  (Though I'm not sure that this is the differentiator in this issue).

I have been able to replicate a scenario where I am inserting new contacts using BulkAPI in serial or parallel mode and get a "corrupt" success file back.

 

In my list of contacts I know (based partially on error returned by the data loader) that I have some "bad" Date-of-Birth data.

I get "Error converting value to correct data type: Date Conversion FAILED" returned in the error file.  And thats ok, I understand why.

 

However the SAME records ALSO are returned in the success file.  And they have ID's assigned.  And after this record each ID assigned to subsequent records is skewed by 1 row.  For example It generates a success file like the following

 

ID                                          Name

003A000000MY64aIAD        Joe-bad-DOB  (who shouldn't be in the success file?)

003A000000MY64bIAD        Bob Jones

003A000000MY64cIAD        JIm Smith

 

but if I paste the Bob Jones id in the url in Salesforce, up comes the Jim Smith record.

 

The skew gets worse (by 1) each time one of these errors is detected. And as far as I can tell its ONLY this specific error that causes this behavior. 

Since one typically uses these success files to create other related objects it can really screw up your data (for instance I was creating relationships to other contacts, which ended up relating totally wrong people).  And was hard to catch in a dataset of 50,000 contacts.  Kinda frustrating if I can't trust the tool (or is it I can't trust me?)

 

I've been doing SFDC dataloading about 2 months.

 

So....bug or user error?  If bug, Salesforce or Lexi?

 

I expect the replication steps to be:

Setup 5 contact records for insert

Put bogus DOB info in the 2nd row to evoke the error.

See if the id's returned for rows 3-5 are "really" their id's.  I'd have done this but all the investigation put me over the "batches / 24 hour" limit....so i"m using the time to post. :)

 

Obviously I'm going to just fix or not map my DOB data for this run to get by this.....but it scares me a little and it burned 12hrs of my time finding it.   More seasoned insight welcome.

 

dave

 

 

 

  • September 01, 2010
  • Like
  • 0

Hi Community,

 

I need to enable a site to my developer org. I registered at https://www.developerforce.com/events/sitespreviewsignup/signin.php already and successfully registered but until now I cannot see the Sites link in my org. Please advise.

 

Thank you in advance,

jma_p

I am running the Lexi Data Loader on a Mac.  (Though I'm not sure that this is the differentiator in this issue).

I have been able to replicate a scenario where I am inserting new contacts using BulkAPI in serial or parallel mode and get a "corrupt" success file back.

 

In my list of contacts I know (based partially on error returned by the data loader) that I have some "bad" Date-of-Birth data.

I get "Error converting value to correct data type: Date Conversion FAILED" returned in the error file.  And thats ok, I understand why.

 

However the SAME records ALSO are returned in the success file.  And they have ID's assigned.  And after this record each ID assigned to subsequent records is skewed by 1 row.  For example It generates a success file like the following

 

ID                                          Name

003A000000MY64aIAD        Joe-bad-DOB  (who shouldn't be in the success file?)

003A000000MY64bIAD        Bob Jones

003A000000MY64cIAD        JIm Smith

 

but if I paste the Bob Jones id in the url in Salesforce, up comes the Jim Smith record.

 

The skew gets worse (by 1) each time one of these errors is detected. And as far as I can tell its ONLY this specific error that causes this behavior. 

Since one typically uses these success files to create other related objects it can really screw up your data (for instance I was creating relationships to other contacts, which ended up relating totally wrong people).  And was hard to catch in a dataset of 50,000 contacts.  Kinda frustrating if I can't trust the tool (or is it I can't trust me?)

 

I've been doing SFDC dataloading about 2 months.

 

So....bug or user error?  If bug, Salesforce or Lexi?

 

I expect the replication steps to be:

Setup 5 contact records for insert

Put bogus DOB info in the 2nd row to evoke the error.

See if the id's returned for rows 3-5 are "really" their id's.  I'd have done this but all the investigation put me over the "batches / 24 hour" limit....so i"m using the time to post. :)

 

Obviously I'm going to just fix or not map my DOB data for this run to get by this.....but it scares me a little and it burned 12hrs of my time finding it.   More seasoned insight welcome.

 

dave

 

 

 

  • September 01, 2010
  • Like
  • 0

I have used the same code as provided for exporting in my application.In Windows the excel gets exported in a proper manner but when I try to export in MAC OS I get the code written inside the script tag from Salesforce's side.Here is the gibberish code that I get

 


if(!window.sfdcPage){window.sfdcPage = new ApexPage();}
UserContext.initialize({'isAccessibleMode':false,'ampm':['AM','PM'],'locale':'en_US','dateTimeFormat':'M/d/yyyy h:mm a','today':'1/28/2009 2:37 AM','dateFormat':'M/d/yyyy','language':'en_US','siteUrlPrefix':'','userPreferences':[{'value':false,'index':119,'name':'HideUserLayoutStdFieldInfo'}
,{'value':false,'index':87,'name':'HideInlineSchedulingSplash'}
,{'value':false,'index':116,'name':'HideRPPWarning'}
,{'value':false,'index':115,'name':'DefaultTaskSendNotification'}
,{'value':false,'index':114,'name':'OverrideTaskSendNotification'}
,{'value':false,'index':112,'name':'HideInlineEditSplash'}
],'startOfWeek':'1'}
);

 

Is this a SalesForce bug or an error from our side.If it is an error do I need to log a bug??