Predict synchronization outcomes

Completed

Change tracking, alternate keys, and the Upsert message each behave in specific, predictable ways. This short activity checks your model of those behaviors before the knowledge check.

Predict the outcome

Before you move on, test your model of what Dataverse does. For each situation, decide what happens before you read the answers. The Device table has an active alternate key on the vendor device code and warehouse code.

  • You send PATCH …/contoso_devices(contoso_vendordevicecode='VEN-5001',contoso_warehousecode='WH-12') with no conditional headers. No record with that key exists.
  • You send the identical request a second time.
  • You send the same kind of request for VEN-5002, which doesn't exist, this time with If-Match: *.
  • Through the SDK, you execute an UpsertRequest for VEN-4471 and WH-12, which already exists, and then check RecordCreated.
  • Since the procurement system's last change-tracking call, device VEN-4473 was updated twice, and device VEN-4480 was created and then deleted. What does the next call return for these two devices?

Check your predictions:

  • Dataverse creates the record and returns 204 No Content.
  • Dataverse finds the record from the first call and updates it. It still returns 204 No Content, and no duplicate is created.
  • Dataverse returns 404 Not Found and creates nothing, because If-Match: * allows only an update.
  • RecordCreated is false, because the call updated an existing record.
  • VEN-4473 comes back once, as a new or updated item with its current values. VEN-4480 comes back as a deleted item, even though the procurement system never had a copy of it.

If any answer surprised you, reread the section it comes from before the knowledge check.