# Bubble Data Upload Not Matching Existing Data in Database

**URL:** <https://forum.bubble.io/t/bubble-data-upload-not-matching-existing-data-in-database/310325>\
**Category:** Database\
**Created:** [March 2, 2024, 8:39pm UTC](https://forum.bubble.io/t/bubble-data-upload-not-matching-existing-data-in-database/310325 "2024-03-02T20:39:48Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\
**Post date:** [March 3, 2024, 6:18pm UTC](https://forum.bubble.io/t/bubble-data-upload-not-matching-existing-data-in-database/310325/5 "2024-03-03T18:18:34Z")

</div>

Likely explanation of your issue @florianherzog :

> [@How To Return Data From Backend API Workflows (no manual API connector)](https://forum.bubble.io/t/how-to-return-data-from-backend-api-workflows-no-manual-api-connector/306357/7):
>
> The behavior you observed is a known issue with option sets where options sometimes use an underlying ID instead of the display value. The underlying ID is set when the option is first created, so there may be a discrepancy between the two if you have changed the display for the option. So, this may cause unexpected results when option sets are used within searches and in API calls.
> 
> You can determine the underlying ID of an option by exporting your application’s JSON, opening the resulting file in a text editor, and doing a text search for the display of the option (or something else that would identify it). The object containing that display will be the definition of the option. If this contains a “db\_value” field, the value for that field is the underlying id. Otherwise, the underlying id is the key pointing to the option’s definition in the containing values object.

---

_[View the full topic](https://forum.bubble.io/t/bubble-data-upload-not-matching-existing-data-in-database/310325)._
