syncFolderItems restriction on numberof ids RRS feed

  • Question

  • Hi,

    I just need to ask if there is any restriction on the size of the  ids list colections for the appointments to be ignored can be passed in syncfolderitems

    ChangeCollection<ItemChange> icc = service.SyncFolderItems(new FolderId(WellKnownFolderName.Inbox), PropertySet.IdOnly, idslist, 10, SyncFolderItemsScope.NormalItems, cSyncState);

    i mean can there be more than 10000 entries in the ids collection.


    Monday, December 5, 2016 10:11 PM

All replies

  • I don't believe there is any restriction but I would recommend against, just think about it your request would have 10000 lines in it make it quite large. You going to get poor performance firstly the server need to receive and process the request and then your forcing the server to process each line, the amount of time consumed by such a request Is more the likely meaning your going to get throttled because of the amount of time the server is spending on your behalf on that operation. Your filtering logic doesn't make any sense if you have to filter that many entries, anybody looking at the requests your application is sending (developer or network admin) is going to look on your application unfavourably if they saw it doing that (IMO).


    Tuesday, December 6, 2016 4:47 AM
  • Hi Glen,

    Many Thanks for your reply. I agree with your point here .Actually i was going through some sort of performance testing and was just thinking anything which can slow down exchange. 

    And your point taken i will not be using it in real world scenarios

    Another question, i know it has been asked many times.

    How can we avoid syncfolderitems to give any past appointment, in case initially i pass sync state as null . i know we can use finditem to get the list of all the ids to be ignored but that does not seems to be reliable , as even passing the list of all the ids does not give up to date sync state for some mail boxes


    Tuesday, December 6, 2016 10:31 AM
  • syncfolderitems will return changes based on the Syncstate you pass it (you shouldn't be getting that many changes between sync call that it should be a huge issue), Maybe your sync logic doesn't suit using that operation and potentially notifications maybe a better option. Synchronization logic can get very complex quickly if its client based you generally need to store something on the client (more the just the Syncstate) it sounds to me your trying to do too much at the server which makes it to complex. With Calendaring I would always have Time frame to sync and don't make it too large 12 months ahead should be fine.


    Wednesday, December 7, 2016 12:57 AM
  • Thanks for your reply glen. 

    I am  actually saving syncstate in database and seems to quite working ok. The only thing i want to control is if pass syncstate as null then i want to avoid any past appointments.

    Not exactly sure what do you mean by 

    With Calendaring I would always have Time frame to sync and don't make it too large 12 months ahead should be fine.

    Wednesday, December 7, 2016 5:33 PM