Am developing an ETL application, which, if I do this right, could be used as an adapter for a major ETL product. Using the objects generated by axis from the WSDL file is not optimal, as the SFDC schema is subject to changes by the user community. Regeneration of the objects is an unwieldy, manual process. describeSObject reveals all the field names and types; What technique can I used besides the getters in the generated objects to retrieve the data values in a query?

Am developing an ETL application, which, if I do this right, could be used as an adapter for a major ETL product. Using the objects generated by axis from the WSDL file is not optimal, as the SFDC schema is subject to changes by the user community. Regeneration of the objects is an unwieldy, manual process. describeSObject reveals all the field names and types; What technique can I used besides the getters in the generated objects to retrieve the data values in a query?

Is there full support in the 3.0 API for multi-byte character support?

Regards;
GlennW

Another quick question.
The SalesForce documentation says both that servers will always be in utf-8 and iso8859-1 encodings, but it also says that it supports such languages as Japanese and Korean whose characters do not fall within those two encodings. How is this handled?

Many thanks.


James Fraumeni
james.fraumeni@activeprime.com

I have been using the PHP SalesForce SOAP client to insert leads into SalesForce; recently, anytime a lead insert call is made and the data contains an accented character (e.g., ö), the call fails and returns an error message in this format:
java.io.UTFDataFormatException: Invalid byte X of Y-byte UTF-8 sequence.

This problem first began on 15 April which is shortly after the various posts regarding the 3.0 API release appeared on the forum. I checked in SalesForce and have confirmed that numerous leads were generated via the same SOAP API call process prior to 13 April when the announcement post about 3.0 issues/bugs was made.
All other calls made without accented characters process fine.

Is anyone else experiencing this problem?

Gritty details:
PHP 4.2.2
PEAR 1.3
PEAR SOAP 0.8RC3 (beta)
URL for connecting to SalesForce = https://www.salesforce.com/services/Soap/u/2.5

--
Luis A. Cruz
lcruz[at]astaro]dot[com

Hello,

I have a customer that requires support for French characters (a Canadian firm).   They have configured sfdc to support this.  I've noticed within an XML log file, that the French char (e with an accent aigu) appears as the hex sequence 0xC3 0xA9, which I believe is correct because IE displays the character appropriately when displaying the XML log itself.

Does anyone have any experience with International characters sets out there?   Perhaps you could shed some light on the convention being used here?  Is the first byte some sort of code page designator, whereas the second byte is the code itself?

Regards,

 

Duke