Woes with copy operation and extended properties in EWS
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I am tasked with bidirectioanlly synching contact folders in two mailboxes with a service.
Please bear with me, as this is the first time I'm using EWS in C#.
In order to uniquely identify items and track changes for synching, I am utilizing SyncFolderHierarchy() for subfolders and SyncFolderItems() for items in each subfolder, while tracking the syncstate.
Since the folder/item IDs are depdendent on the mailbox, on initial sync, as well as on Create operations, I am tagging synched items with an extended property via Item.SetExtendedProperty()
This works really well, but I have run into a caveat.
When a user copies and pastes a folder or contact in Outlook, it also copies the unique ID (extended property), making it not-so-unique anymore.
In that case, I now have two items in a mailbox with the same "unique" ID, and now have an ambiguous match for the item.
Basically:
SyncFolderItems()is invoked, and sync state saved- Item is tagged with unique ID if it doesn't have one
- User copies and pastes the item
SyncFolderItems()is invoked (with previous sync state), returns aCreateevent for user-copied item- Item that is created already has a unique ID
Now, one might argue just overwrite the unique ID for an item in a create event.
However, this leads to the following issue:
When I sync a new item from mailbox A into mailbox B, I also create an item.
Once SyncFolderItems() on mailbox A is now invoked, I also retrieve a Create event for my own item, which in this case legitimately already has a unique ID assigned that must not be overwritten.
I basically see two options:
Somehow prevent this extended property from being copyable
Prevent EWS from sending a create for an item I created myself.
I am aware I can ignore ItemIDs in aSyncFolderItems()call, but I am not sure how I should track the item IDs across calls because they may change according to the documentation
Does anyone have any suggestions on how to approach this differently or implement either option??
c# exchangewebservices extended-properties
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
add a comment |
I am tasked with bidirectioanlly synching contact folders in two mailboxes with a service.
Please bear with me, as this is the first time I'm using EWS in C#.
In order to uniquely identify items and track changes for synching, I am utilizing SyncFolderHierarchy() for subfolders and SyncFolderItems() for items in each subfolder, while tracking the syncstate.
Since the folder/item IDs are depdendent on the mailbox, on initial sync, as well as on Create operations, I am tagging synched items with an extended property via Item.SetExtendedProperty()
This works really well, but I have run into a caveat.
When a user copies and pastes a folder or contact in Outlook, it also copies the unique ID (extended property), making it not-so-unique anymore.
In that case, I now have two items in a mailbox with the same "unique" ID, and now have an ambiguous match for the item.
Basically:
SyncFolderItems()is invoked, and sync state saved- Item is tagged with unique ID if it doesn't have one
- User copies and pastes the item
SyncFolderItems()is invoked (with previous sync state), returns aCreateevent for user-copied item- Item that is created already has a unique ID
Now, one might argue just overwrite the unique ID for an item in a create event.
However, this leads to the following issue:
When I sync a new item from mailbox A into mailbox B, I also create an item.
Once SyncFolderItems() on mailbox A is now invoked, I also retrieve a Create event for my own item, which in this case legitimately already has a unique ID assigned that must not be overwritten.
I basically see two options:
Somehow prevent this extended property from being copyable
Prevent EWS from sending a create for an item I created myself.
I am aware I can ignore ItemIDs in aSyncFolderItems()call, but I am not sure how I should track the item IDs across calls because they may change according to the documentation
Does anyone have any suggestions on how to approach this differently or implement either option??
c# exchangewebservices extended-properties
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
Direct synching between two databases requires that the keys are actually unique. As you said, they are not doing that properly. So you need a 3rd Database. Some file format or other where you and only you gave out the primary keys. That way you got control and can maintain that each key is actually unique.
– Christopher
Nov 23 '18 at 17:40
Yes, I was thinking about keeping track in a sqlite. However, on copy, Exchange would still duplicate the unique key I assigned to an item, or in database terms, violate that constraint. So keeping the key in a third place would still result in an ambiguous match :/
– namezero
Nov 23 '18 at 18:29
@Christopher Just to clarify: You mean keep all sync IDs ever issued, and when a change event comes with a syncID never seen before, ignore it? I'm currently thinking about caveats and might try this out...
– namezero
Nov 23 '18 at 18:41
My point is to ignore the key in Exchange. It is not reliable and propably never will be. You might even be missusing a field that was not intended for primary keys. Have a 3rd databsae. Let it be the authority on the state of of both endpoints.
– Christopher
Nov 23 '18 at 19:01
@Christopher Yes, ok, so let me ask: it seems the ItemID/FolderID is not guaranteed to stay the same. So if I store it in a master database, how can I match an item to the master database on aSyncFolderItems()call? The code example at docs.microsoft.com/en-us/previous-versions/office/developer/… only mentions "Todo: Update / Delete / ... item on client" andic.ItemId.UniqueId: Is the ItemID (or uniqueID) here guranteed to match something seen before?
– namezero
Nov 23 '18 at 20:11
add a comment |
I am tasked with bidirectioanlly synching contact folders in two mailboxes with a service.
Please bear with me, as this is the first time I'm using EWS in C#.
In order to uniquely identify items and track changes for synching, I am utilizing SyncFolderHierarchy() for subfolders and SyncFolderItems() for items in each subfolder, while tracking the syncstate.
Since the folder/item IDs are depdendent on the mailbox, on initial sync, as well as on Create operations, I am tagging synched items with an extended property via Item.SetExtendedProperty()
This works really well, but I have run into a caveat.
When a user copies and pastes a folder or contact in Outlook, it also copies the unique ID (extended property), making it not-so-unique anymore.
In that case, I now have two items in a mailbox with the same "unique" ID, and now have an ambiguous match for the item.
Basically:
SyncFolderItems()is invoked, and sync state saved- Item is tagged with unique ID if it doesn't have one
- User copies and pastes the item
SyncFolderItems()is invoked (with previous sync state), returns aCreateevent for user-copied item- Item that is created already has a unique ID
Now, one might argue just overwrite the unique ID for an item in a create event.
However, this leads to the following issue:
When I sync a new item from mailbox A into mailbox B, I also create an item.
Once SyncFolderItems() on mailbox A is now invoked, I also retrieve a Create event for my own item, which in this case legitimately already has a unique ID assigned that must not be overwritten.
I basically see two options:
Somehow prevent this extended property from being copyable
Prevent EWS from sending a create for an item I created myself.
I am aware I can ignore ItemIDs in aSyncFolderItems()call, but I am not sure how I should track the item IDs across calls because they may change according to the documentation
Does anyone have any suggestions on how to approach this differently or implement either option??
c# exchangewebservices extended-properties
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
I am tasked with bidirectioanlly synching contact folders in two mailboxes with a service.
Please bear with me, as this is the first time I'm using EWS in C#.
In order to uniquely identify items and track changes for synching, I am utilizing SyncFolderHierarchy() for subfolders and SyncFolderItems() for items in each subfolder, while tracking the syncstate.
Since the folder/item IDs are depdendent on the mailbox, on initial sync, as well as on Create operations, I am tagging synched items with an extended property via Item.SetExtendedProperty()
This works really well, but I have run into a caveat.
When a user copies and pastes a folder or contact in Outlook, it also copies the unique ID (extended property), making it not-so-unique anymore.
In that case, I now have two items in a mailbox with the same "unique" ID, and now have an ambiguous match for the item.
Basically:
SyncFolderItems()is invoked, and sync state saved- Item is tagged with unique ID if it doesn't have one
- User copies and pastes the item
SyncFolderItems()is invoked (with previous sync state), returns aCreateevent for user-copied item- Item that is created already has a unique ID
Now, one might argue just overwrite the unique ID for an item in a create event.
However, this leads to the following issue:
When I sync a new item from mailbox A into mailbox B, I also create an item.
Once SyncFolderItems() on mailbox A is now invoked, I also retrieve a Create event for my own item, which in this case legitimately already has a unique ID assigned that must not be overwritten.
I basically see two options:
Somehow prevent this extended property from being copyable
Prevent EWS from sending a create for an item I created myself.
I am aware I can ignore ItemIDs in aSyncFolderItems()call, but I am not sure how I should track the item IDs across calls because they may change according to the documentation
Does anyone have any suggestions on how to approach this differently or implement either option??
c# exchangewebservices extended-properties
c# exchangewebservices extended-properties
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
edited Nov 23 '18 at 18:27
namezero
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
asked Nov 23 '18 at 17:22
namezeronamezero
1,33531733
1,33531733
Direct synching between two databases requires that the keys are actually unique. As you said, they are not doing that properly. So you need a 3rd Database. Some file format or other where you and only you gave out the primary keys. That way you got control and can maintain that each key is actually unique.
– Christopher
Nov 23 '18 at 17:40
Yes, I was thinking about keeping track in a sqlite. However, on copy, Exchange would still duplicate the unique key I assigned to an item, or in database terms, violate that constraint. So keeping the key in a third place would still result in an ambiguous match :/
– namezero
Nov 23 '18 at 18:29
@Christopher Just to clarify: You mean keep all sync IDs ever issued, and when a change event comes with a syncID never seen before, ignore it? I'm currently thinking about caveats and might try this out...
– namezero
Nov 23 '18 at 18:41
My point is to ignore the key in Exchange. It is not reliable and propably never will be. You might even be missusing a field that was not intended for primary keys. Have a 3rd databsae. Let it be the authority on the state of of both endpoints.
– Christopher
Nov 23 '18 at 19:01
@Christopher Yes, ok, so let me ask: it seems the ItemID/FolderID is not guaranteed to stay the same. So if I store it in a master database, how can I match an item to the master database on aSyncFolderItems()call? The code example at docs.microsoft.com/en-us/previous-versions/office/developer/… only mentions "Todo: Update / Delete / ... item on client" andic.ItemId.UniqueId: Is the ItemID (or uniqueID) here guranteed to match something seen before?
– namezero
Nov 23 '18 at 20:11
add a comment |
Direct synching between two databases requires that the keys are actually unique. As you said, they are not doing that properly. So you need a 3rd Database. Some file format or other where you and only you gave out the primary keys. That way you got control and can maintain that each key is actually unique.
– Christopher
Nov 23 '18 at 17:40
Yes, I was thinking about keeping track in a sqlite. However, on copy, Exchange would still duplicate the unique key I assigned to an item, or in database terms, violate that constraint. So keeping the key in a third place would still result in an ambiguous match :/
– namezero
Nov 23 '18 at 18:29
@Christopher Just to clarify: You mean keep all sync IDs ever issued, and when a change event comes with a syncID never seen before, ignore it? I'm currently thinking about caveats and might try this out...
– namezero
Nov 23 '18 at 18:41
My point is to ignore the key in Exchange. It is not reliable and propably never will be. You might even be missusing a field that was not intended for primary keys. Have a 3rd databsae. Let it be the authority on the state of of both endpoints.
– Christopher
Nov 23 '18 at 19:01
@Christopher Yes, ok, so let me ask: it seems the ItemID/FolderID is not guaranteed to stay the same. So if I store it in a master database, how can I match an item to the master database on aSyncFolderItems()call? The code example at docs.microsoft.com/en-us/previous-versions/office/developer/… only mentions "Todo: Update / Delete / ... item on client" andic.ItemId.UniqueId: Is the ItemID (or uniqueID) here guranteed to match something seen before?
– namezero
Nov 23 '18 at 20:11
Direct synching between two databases requires that the keys are actually unique. As you said, they are not doing that properly. So you need a 3rd Database. Some file format or other where you and only you gave out the primary keys. That way you got control and can maintain that each key is actually unique.
– Christopher
Nov 23 '18 at 17:40
Direct synching between two databases requires that the keys are actually unique. As you said, they are not doing that properly. So you need a 3rd Database. Some file format or other where you and only you gave out the primary keys. That way you got control and can maintain that each key is actually unique.
– Christopher
Nov 23 '18 at 17:40
Yes, I was thinking about keeping track in a sqlite. However, on copy, Exchange would still duplicate the unique key I assigned to an item, or in database terms, violate that constraint. So keeping the key in a third place would still result in an ambiguous match :/
– namezero
Nov 23 '18 at 18:29
Yes, I was thinking about keeping track in a sqlite. However, on copy, Exchange would still duplicate the unique key I assigned to an item, or in database terms, violate that constraint. So keeping the key in a third place would still result in an ambiguous match :/
– namezero
Nov 23 '18 at 18:29
@Christopher Just to clarify: You mean keep all sync IDs ever issued, and when a change event comes with a syncID never seen before, ignore it? I'm currently thinking about caveats and might try this out...
– namezero
Nov 23 '18 at 18:41
@Christopher Just to clarify: You mean keep all sync IDs ever issued, and when a change event comes with a syncID never seen before, ignore it? I'm currently thinking about caveats and might try this out...
– namezero
Nov 23 '18 at 18:41
My point is to ignore the key in Exchange. It is not reliable and propably never will be. You might even be missusing a field that was not intended for primary keys. Have a 3rd databsae. Let it be the authority on the state of of both endpoints.
– Christopher
Nov 23 '18 at 19:01
My point is to ignore the key in Exchange. It is not reliable and propably never will be. You might even be missusing a field that was not intended for primary keys. Have a 3rd databsae. Let it be the authority on the state of of both endpoints.
– Christopher
Nov 23 '18 at 19:01
@Christopher Yes, ok, so let me ask: it seems the ItemID/FolderID is not guaranteed to stay the same. So if I store it in a master database, how can I match an item to the master database on a
SyncFolderItems() call? The code example at docs.microsoft.com/en-us/previous-versions/office/developer/… only mentions "Todo: Update / Delete / ... item on client" and ic.ItemId.UniqueId: Is the ItemID (or uniqueID) here guranteed to match something seen before?– namezero
Nov 23 '18 at 20:11
@Christopher Yes, ok, so let me ask: it seems the ItemID/FolderID is not guaranteed to stay the same. So if I store it in a master database, how can I match an item to the master database on a
SyncFolderItems() call? The code example at docs.microsoft.com/en-us/previous-versions/office/developer/… only mentions "Todo: Update / Delete / ... item on client" and ic.ItemId.UniqueId: Is the ItemID (or uniqueID) here guranteed to match something seen before?– namezero
Nov 23 '18 at 20:11
add a comment |
1 Answer
1
active
oldest
votes
The Exchange id should really be your unique id as well. It is really not worth it to keep your id on the item itself - firstly, that requires a modification of that item (and that will generate a change event even though it was you who caused the change), and secondly, as you have already noticed, you can end up with duplicates or triplicates of the same item.
It is even worse for the appointments - each incoming appointment update causes Outlook to recreate the appointment, causing a new id to be used and wiping out your custom property.
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… statesDon't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?
– namezero
Nov 24 '18 at 7:15
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
1
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450772%2fwoes-with-copy-operation-and-extended-properties-in-ews%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The Exchange id should really be your unique id as well. It is really not worth it to keep your id on the item itself - firstly, that requires a modification of that item (and that will generate a change event even though it was you who caused the change), and secondly, as you have already noticed, you can end up with duplicates or triplicates of the same item.
It is even worse for the appointments - each incoming appointment update causes Outlook to recreate the appointment, causing a new id to be used and wiping out your custom property.
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… statesDon't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?
– namezero
Nov 24 '18 at 7:15
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
1
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
add a comment |
The Exchange id should really be your unique id as well. It is really not worth it to keep your id on the item itself - firstly, that requires a modification of that item (and that will generate a change event even though it was you who caused the change), and secondly, as you have already noticed, you can end up with duplicates or triplicates of the same item.
It is even worse for the appointments - each incoming appointment update causes Outlook to recreate the appointment, causing a new id to be used and wiping out your custom property.
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… statesDon't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?
– namezero
Nov 24 '18 at 7:15
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
1
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
add a comment |
The Exchange id should really be your unique id as well. It is really not worth it to keep your id on the item itself - firstly, that requires a modification of that item (and that will generate a change event even though it was you who caused the change), and secondly, as you have already noticed, you can end up with duplicates or triplicates of the same item.
It is even worse for the appointments - each incoming appointment update causes Outlook to recreate the appointment, causing a new id to be used and wiping out your custom property.
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
The Exchange id should really be your unique id as well. It is really not worth it to keep your id on the item itself - firstly, that requires a modification of that item (and that will generate a change event even though it was you who caused the change), and secondly, as you have already noticed, you can end up with duplicates or triplicates of the same item.
It is even worse for the appointments - each incoming appointment update causes Outlook to recreate the appointment, causing a new id to be used and wiping out your custom property.
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
answered Nov 23 '18 at 23:23
Dmitry StreblechenkoDmitry Streblechenko
44.9k32860
44.9k32860
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… statesDon't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?
– namezero
Nov 24 '18 at 7:15
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
1
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
add a comment |
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… statesDon't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?
– namezero
Nov 24 '18 at 7:15
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
1
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… states
Don't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?– namezero
Nov 24 '18 at 7:15
Thanks for the input, Dmitry. I was just wary of using it because the docs.microsoft.com/en-us/exchange/client-developer/… states
Don't assume that your ID will always be valid if you need to retrieve the item at a later time. Of course I would much rather use this ID than finicking around with a custom property! So you say the ID in a ChangeState will be something seen before?– namezero
Nov 24 '18 at 7:15
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
As long as the item is there, you should be able to use it. If not, you can assume that the item was deleted / recreated /moved to a different mailbox / etc.
– Dmitry Streblechenko
Nov 25 '18 at 1:12
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
Thanks. I am currently working on the implementation and will report / accept next week if it works!
– namezero
Nov 25 '18 at 20:09
1
1
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
Mapping both side's ItemIds and FolderIds to each other in a database is of course tedious, but appears to work well.
– namezero
Dec 2 '18 at 16:16
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53450772%2fwoes-with-copy-operation-and-extended-properties-in-ews%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Direct synching between two databases requires that the keys are actually unique. As you said, they are not doing that properly. So you need a 3rd Database. Some file format or other where you and only you gave out the primary keys. That way you got control and can maintain that each key is actually unique.
– Christopher
Nov 23 '18 at 17:40
Yes, I was thinking about keeping track in a sqlite. However, on copy, Exchange would still duplicate the unique key I assigned to an item, or in database terms, violate that constraint. So keeping the key in a third place would still result in an ambiguous match :/
– namezero
Nov 23 '18 at 18:29
@Christopher Just to clarify: You mean keep all sync IDs ever issued, and when a change event comes with a syncID never seen before, ignore it? I'm currently thinking about caveats and might try this out...
– namezero
Nov 23 '18 at 18:41
My point is to ignore the key in Exchange. It is not reliable and propably never will be. You might even be missusing a field that was not intended for primary keys. Have a 3rd databsae. Let it be the authority on the state of of both endpoints.
– Christopher
Nov 23 '18 at 19:01
@Christopher Yes, ok, so let me ask: it seems the ItemID/FolderID is not guaranteed to stay the same. So if I store it in a master database, how can I match an item to the master database on a
SyncFolderItems()call? The code example at docs.microsoft.com/en-us/previous-versions/office/developer/… only mentions "Todo: Update / Delete / ... item on client" andic.ItemId.UniqueId: Is the ItemID (or uniqueID) here guranteed to match something seen before?– namezero
Nov 23 '18 at 20:11