#exchange-server #exchangewebservices #ews-managed-api
#exchange-сервер #exchangewebservices #ews-managed-api
Вопрос:
У нас есть служба, которая синхронизирует наш календарь с календарем exhange. В процессе синхронизации мы используем уникальные идентификаторы для идентификации встреч. Теперь у нас есть клиент, у которого есть неуникальные уникальные идентификаторы.
Я использовал EWSEditor (https://github.com/dseph/EwsEditor ) для проверки элементов и да, обе встречи (тот же пользователь, тот же месяц, тот же уникальный идентификатор, но другая встреча) имеют точно такой же уникальный идентификатор.
Обе встречи не создаются с помощью нашего программного обеспечения. Они создаются пользователем вручную через Outlook.
Есть ли причина, по которой exchange создает встречи с одинаковыми идентификаторами?
Ответ №1:
Вы говорите, что идентификатор был использован повторно (если это возможно, поскольку он все равно будет уникальным). Или вы говорите, что у вас есть два одинаковых идентификатора в одном календаре, если да, то уверены ли вы, что ваши повторяющиеся встречи не сбивают с толку или тот факт, что UnqiueId имеют кодировку base64, поэтому это означает, что идентификаторы чувствительны к регистру.
Тем не менее, использование UniqueID для назначения в календаре не является отличной идеей, и вам было бы лучше использовать свойство GOID, такое как PidLidCleanGlobalObjectId https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidlidcleanglobalobjectid-canonical-property
Комментарии:
1. Я обнаружил проблему… Вы дали мне правильный намек… Мой разум был похож… «эй, наверняка это тот же идентификатор, тот же идентификатор, с правильным корпусом». Но … этого не было. Второй идентификатор имеет другую оболочку. После того, как моя функция выдала мне предупреждение о том, что есть «совпадение идентификаторов», которого не должно было произойти, я проверил значения в своем редакторе, и там функция сравнения не учитывала регистр. У самой функции (которая является всего лишь проверкой безопасности) возникла проблема внутри его SQL-запроса. Оператор был правильным (=), но сортировка полей была без учета регистра. (SQL_Latin1_General_CP1_CI_AS) Итак, … спасибо 🙂