>>>>>>>>>>What is the need for randomness? Not clear from the post. Why not ask the server for a unique ID if GUID is considered too flakey?
>>>>>>>>>
>>>>>>>>>Don't think GUIDs are flaky (at least compared to other options). If you ask a server to generate an ID (what are you suggesting? An int?) you have problems with overlapping hits......
>>>>>>>>
>>>>>>>>calling into DB table, creating records with candidate key, perhaps with some rules invalidating to stem growth without prune
>>>>>>>
>>>>>>>But why bother ?
>>>>>>
>>>>>>There are a couple of UC where the device / endpoint making changes has to be logged as well. -If/When the ID of the device has to enter the "DB space", the mechanics of the DB might be used again. Embolded part of my original post does not imply I think GUID is especially untrustworthy, but if there are very demanding specs I'd trust a DB based ID generating mechanism more.
>>>>>
>>>>>But, to be safe, the table issuing Ids would need to be locked on each request. That means multiple requests would essentially be handled in a serial fashion - bit of a bottle neck on a web server ?
>>>>
>>>>If the server bottlenecks measurably creating new records with candidate ID's the whole project is in trouble if adding info is in the specs ;-))
>>>
>>>Exactly. So why not use GUIDs ?
>>
>>Let me describe why I am still not 100% convinced the GUID is the way to go, for MY specific case. First, why I need this unique ID.
>>
>>One of the features of the application (that will be running on the tablet) is that user, every week or so, will create a list of XML files. E.g PM_123.XML, PM_ABC.XML, and so on. I need to 'tag' these XML files as belonging to this particular tablet (not user, because different users may log into this tablet at different times). So my idea is to create an XML file that will "enclose" the XML files created by user/tablet. For example:
>>

>><MyFile>
>>   <File>
>>       <FileName>PM_123.xml</FileName>
>>      <DeviceID>001</DeviceID>
>>  </File>
>>   <File>
>>       <FileName>PM_ABC.xml</FileName>
>>      <DeviceID>001</DeviceID>
>>  </File>
>>   <File>
>>       <FileName>PM_123.xml</FileName>
>>      <DeviceID>002</DeviceID>
>>  </File>
>></MyFile>
>>

>>
>>Then, when a particular device needs to find all XML files that "belong/tagged" by this device, the program will get all file names from the above XML file that belong to the device "001" (or "002"). This device ID (e.g. '001', '002') will be saved in the LocalStorage.
>>
>>The problem with GUID is possible as follows. Say a device loses localstorage. And the unique ID identified in the above XML and in the local storage is a long string of a random key. I will have a hard time finding and recreating the "connection" between the device and the files that belong to this device.
>>
>>This is why I would like the unique ID to be a little more "descriptive" so that, in case the local storage is lost, I can recreate a connection.
>>
>>I hope my long description makes sense.
>
>I'm afraid I don't understand. If the device loses it's ID (whether it be a GUID or something else) how will you re-create the link to it's file list ?
>Might be worth looking at this: https://github.com/Valve/fingerprintJS (claims 94% accuracy but I've no idea how true that is).
>
>>And I am listening very attentively to alternative suggestions.
>
>I'd either:
>(a) Rejig the XML for compactness and speed of lookup:

<Devices>
>   <Device ID=001>
>     <FileName>PM_123.xml</FileName>
>      <FileName>PM_ABC.xml</FileName>
>  </Device>
>  <Device ID=002>
>     <FileName>PM_123.xml</FileName>
>  </Device>
></Devices>

or just store the file list on localStorage on the Device and request the data from the server from there. If you store the list on the server and an Id is lost then you've no way of cleaning out redundant entries and it removes the need for a device ID in the first place.

Thank you for suggestions to change the XML. And thank you for the idea of storing the files names in the local storage. I like this. Initially I thought I would store the entire XML to the local storage (if you remember my mumbling a few threads ago :). But the XML files could be very big and there could be many of them (100 or more). So I decided the local storage does not have enough capacity for the entire XML. But the names should fit very well.
Thank you!