Changes have been made in Git for this ticket:

Bug #10008: DB query might be empty

  1 files changed, 9 insertions(+), 8 deletions(-)
http://git.horde.org/horde-git/-/commit/a1bafdb2e26b85a7c44bc71944cab7f6c1a7a8b9

I think, there still is a problem:

public function readSyncAnchors($databaseURI)
             $res = $this->_db->selectOne($query, $values);
             return array(
                 $res['syncml_clientanchor'],
                 $res['syncml_serveranchor']
             );

This returns an array.

In Line 537 in
public function writeSyncAnchors($databaseURI, $clientAnchorNext,
                               $serverAnchorNext)
there is an
  if (!$this->readSyncAnchors($databaseURI))


Hence, this fix only works, if an entry is already present and only 
UPDATE is called. If no entry is present, there will never be an 
INSERT and thus only slow sync occurs.

Your fix works also for me.
Thanks for helping!

- Tom

The patch fixed the problem for me! (although the previous change from 
the previous comment did it, too)

Then this is wrong, since readSyncAnchors() clearly states it needs to 
be a two element array.  So your fix isn't correct.

Looks like the real issue is in Horde_SyncMl_Backend_Horde.  See if 
this patch fixes things.

Changes have been made in Git for this ticket:

Bug #10008: Fix issue causing slow syncs only

  2 files changed, 10 insertions(+), 2 deletions(-)
http://git.horde.org/horde-git/-/commit/c849aaf457003d830f208eba0c8625339575a8b8

EDIT:

Got it working (for me at last) by changing line 166 (the list() 
function with the two lines:

$clientlast = $r[syncml_clientanchor];
$serverAnchorLast = $r[syncml_serveranchor];

$r seems to be a Associative array.

- Tom

I took some time to dive a little bit into this.
It looks like the Function
  list($clientlast, $serverAnchorLast) = $r;
  on line 166 of Command/Alert.php ist not performing as expected.
The array seems to be there in $r, because adding
  . implode ("||",$r);
in the logMessage (line167) issuses both values as recorderd in the Database.
But the variables $clientlast and $serverAnchorLast are still empty 
when printed in the logMessage.

  -Tom

Horde only does slow syncs with my N900 client (syncevolution), but 
other users have reported similar problems on the mailing lists. As 
Jan stated, it seems that Horde fails to read the timestamp of the 
last sync from the database.

I tried to produce a clean log. Here is what I did:

1. rm everything in /tmp/sync
2. horde log output set to "Debug"
3. dropped all horde_syncml tables and recreated them using the horde
configuration and deleted all turba contacts and calender items
4. deleted everything in ~/.cache/syncevolution on the n900
5. manually initiated slow sync with syncevolution with

'syncevolution --sync refresh-from-client  <myconfigname>'

That worked flawlessly.

6. Initiated a "normal" two-way sync with 'syncevolution <myconfigname>'

Same problem again. Horde can't seem to find the timestamp:

UNKNOWN:Previous sync found for database contacts; client timestamp:
UNKNOWN:Client requested sync with anchor timestamp 20110426T173321Z 
but server has recorded timestamp . Enforcing SlowSync

Attached to this bug there is a tarball which contains:

- Horde /tmp/sync folder contents (synclogs.tgz)
- Syncevolution output during slow sync (syncevolution_output_slow_sync)
- Syncevolution output during normal sync (syncevolution_output_normal_sync)
- content of the horde_* database tables (horde_syncml.sql)