Is it calculated on the basis of the items location? The data/time the link is produced? Other parameters? Is it conceivable to reconstruct them or reverse engineer them somehow?
I am trying to identify what documents a number of broken links refer to, based on an old backup of my database.
Thanks.
I think I am figuring it out—one step at a time: Do I assume correctly that the database UUID is also factored in?
If so, I am facing a disaster. A few days ago I created a new database and dragged-and-dropped several items (indexed, for that matter) from the old database into the new one.
Could it be that these items were assigned a new x-devonthink-item address when dropped in the new database??
OK, I confirmed that x-devonthink-item:// links are database-specific.
Question: if there was a way to change the UUID of my new database so as to match that of the old one, would that also fix the links? I very much hope so.
If you duplicate the database in Finder the duplicate with have the same database UUID. However that causes a host of frustrating problems.
All of this is verifiable by inspection and testing:
Your problem is due to something else.
Well, the problem is that I created new blank database and drag-and-dropped hundreds of linked and imported items from one (old) database to the new one. As a result of this operation, I presume, my x-devonthink-item links are broken. This is pretty serious in my case because I have a very tight-knit wiki-like database, in addition to referencing my DevonThink items in other applications (e.g. BibDesk).
The reason I created this new database was that the original one presented problems with syncing and, following Jim’s suggestion, I assumed that moving my data into a new database would solve them (as it did, if only partly). Little did I know that I’d pay with the integrity of my links by doing so.
Open a ticket with Support.
The reference URL does not change when dragging and dropping between databases.
Even if you create a Rich Text document, Command-Option drag a file to create a document link, then move either the document or the linked document to another database, the links still function.
Exporting / Importing Files and Folders will create a new reference URL, as these files are new to the database.
Hmm… good to know, Jim, thanks. Ceasing fire for now, while I’m fixing up my DB. Should take 4-5 more hrs. 
Just as a further clarification…
Replicants will have the same reference URL as the replicated file.
Duplicates will have a new reference URL.
So, all in all, what is the reference URL a function of? File name? File contents? Time and date at the moment the URL is created? Just asking to increase my confidence levels as I do this extensive database surgery.
It’s not a function of any of these items. It is just a unique identifier pointing to a specific file. en.wikipedia.org/wiki/Universal … identifier
Got it. Overthinking–a sign of distress.
No problem. It’s similar to the US Social Security Number (though SSN’s are not randomly generated). Once you get a number, it always refers to you, regardless of your location or even if you change your name. (A name is just a piece of convenience metadata, for your own organizational needs.) In fact, you could technically change the name of every record in your database and the UUID would remain the same, hence the reference URL would always work.
Note the difference between the hyperlink in the RTF document and the changed name it points at…
PS: Breathe in. Hold for a count of three. Breathe out. Repeat. 