[sync] Backend/Sql.php bug fix; possible Outlook/Funambol server to client fix

[Karsten Fourmont]

Hi,

thanks for the feedback. I'm delighted to hear that someone actually 
uses the sql.php backend.

I fixed the Outlook/Funambol issue in Sync4j.php, see my previous post 
on the syncml list.

Cheers,
  Karsten

Scott Everson wrote:
> Hi everyone,
> 
> I have recently take on integrating the Horde SyncML packages into our CRM.
> During the process, I have found a couple of things that might be helpful to
> others and upcoming releases.
> 
> I am using the Backend/Sql.php and setup my database with the structure
> defined in the comment block at top.   After testing, I found that the code
> pointed to the wrong column in the syncml_anchors table.  Line 620
> (readySyncAnchors() query) refers to 'syncid' and it should be
> 'syncml_syncpartner'
> 
> I also ran into the same problem with Outlook/Funambol not being able to
> send data from the Server to the Client.  The client kept telling me garbage
> data was received and after some crazy debugging, I found that the server
> was sending the raw vcard formatted data, not the crazy sifc format that
> Funambol is wanting.   So, I found a quick fix to SyncML/Device/Sync4j.php:
> In the convertServer2Client() method, the case statement on $contentType was
> failing because it was being given (in the case of a contact)
> 'text/x-s4j-sifc' when the case was expecting 'text/x-vcard'.  I updated the
> case statement to check for the sifc type as well, and now I can receive
> contacts!  I am assuming this will work for the other types but I have not
> tested this yet.  
> 
> case 'text/x-s4j-sifc':
> case 'text/x-vcard' :
> ...
> 
> My guess is that the problem is really at the source -- why is the vcard
> data being labeled as sifc data.. Or is the calling method requesting that
> sifc data be returned, but the convertServer2Client() is treating
> contentType as what is given instead..
> 
> Hope you find this helpful,