If you have to revisit the same household again, having a hint about the location in the ID could help surveyors be sure they are pulling up the correct record when they revisit the respondent. However, if you do want to incorporate a randomly generated ID, we’d suggest using some kind of location information in the ID as well. In this example form, a 6 character random ID is generated and you can choose a custom length of ID. Alternatively, click here to see an example form demonstrating a longer process which can be used to generate a more customisable ID. "once(uuid(7))" to return a 7 digit random ID). Give uuid() an integer value to get a random ID of that length (e.g. uuid() should be used with once() (as in "once(uuid())"). Do this most simply with Surve圜TO's uuid() function in a calculate field to create and ID that is a random combination of numbers and letters. In our experience, a random number of 7 digits is sufficiently random, to avoid duplicate IDs. province, district, village) as part of a cascading select, and even a random number or sequence.Īlternatively, you can rely upon a randomly generated ID. This could include parts of the date and time, area levels (e.g. If this is a baseline project where you are visiting new respondents for the first time, you might want to create IDs using values in your form using the concat() function in a calculate field. So, keeping that in mind, here are some strategies that you can consider depending on the specifics of your project. That might not be true though! What if the first instance of ID 1234 was an error? In this case you wouldn’t want to discard one of the instances - you'd want to receive that data to protect it and resolve conflicts later.
A system like this might declare the first instance of ID 1234 as valid and any others that follow invalid.
Then enumerator B uploads records after, also including a submission with study ID 1234. Enumerator A uploads submissions first, with study ID 1234 amongst them.
#123d design duplicate Offline
For example, let’s say your enumerators work offline for a few days. It is not possible to designate another field in the form which contains your study ID for the server to monitor.Įven if there were such a feature, there would be unavoidable conflicts that you'd need to work through. The KEY is actually determined at the moment of finalization of the form, and that is the only factor the server takes into account when deciding whether to accept a submission or not. There are however, measures for minimising the problem and making duplicates less likely.įirstly, there isn't a direct feature for the server to control submissions according to a duplicate value which isn't the KEY value. As a result, there is no 100% airtight solution for guarding against duplicates study IDs. When a blank form opens, it is blind as to what is on the server and what is being recorded inside other blank instances of the same form. You're probably thinking in terms of your study ID system, right? One household or individual has a study ID and you wish to prevent the same household or individual from being assessed/interviewed a second time, and you wish to prevent the same study ID from being used again in error, for the wrong household or individual. What you have in mind as a unique ID is probably different than the automatically generated UUID. Strategies for preventing duplicate entries To understand additional columns including KEY, read more here: understanding the format of exported data. Note: KEY is one of a few additional columns that appear in exported data. If you submit that same survey more than once, it will only be accepted the first time. When you finalize a Surve圜TO survey, either in the Surve圜TO Collect app or via the web interface, Surve圜TO generates a UUID for that record that the server will use to make sure that there is only ever one copy of that record in your ‘master’ database. UUID is an acronym for “universally unique identifier” and when one is generated using standard methods, the chance of it matching any other in the world is so marginal as to functionally be zero. csvs you’ve probably noticed the "KEY" column, and in that column, values that start with ‘uuid:’ followed by what might look like an indecipherable code.
If you have ever taken a close look at your exported. How Surve圜TO identifies records internallyīefore we get into the how-to portion of this article, I should clarify that even if you never set up a way to uniquely identify your own records, Surve圜TO has an internal system to prevent duplicate submissions.
0 kommentar(er)
