I have found many questions in this forum asking how to prevent profile documents from being replicated but no recent ones. Does it mean that there is a way to do it now or does it mean that everybody has just given up?
If someone knows how to prevent replication of profile documents, PLEASE let me know! But please don’t start a discussion like “why don’t you want them to replicate?”. There are good reasons why profile documents should be local and not spread over all replicas.
Ruedi
Subject: Prevent replication of profile documents
If you want documents to be “local only” then Profile documents are not the way to go.
Create normal documents to store the values, and get to them by view lookups. You should have a field with the server’s name, so lookups would always select the document relative to the server the replication copy is on. Then it does not matter if they replicate or not.
Your only other option would be Selective Replication (which personally, I’ve never been a fan of as you cannot control how users replicate.).
i.e. Replicate all documents where Dont_Replicate != “Yes” and add that value to your profile documents.
But that’s not robust. It could fail if someone makes a full local replica, and replicates with two different server copies.
As an aside, I’ve stopped using Profile Documents completely after we were hit by a nasty bug.
User started a new replica, but interrupted it.
The profile document had not replicated.
The user opened the partially replicated database, creating a new blank profile document
The user completed the replication, which copied the blank profile back to the server
This, of course, destroyed the field values on the server’s document, and as profile documents cannot create replication conflicts, we could not easily correct that.
So my advice would be to consider not using them at all, and stick to normal documents.
Subject: RE: Prevent replication of profile documents
Makes sense, though profile documents have advantages as well.
Unfortunately selective replication does not seem to work with profile documents. Replication simply ignores the selection formula. Would be great to know wheter this is done on purpose or wheter it is a bug.
Ruedi
Subject: RE: Prevent replication of profile documents
Profile documents ignoring selective replication is a deliberate feature. Too many people were creating local replicas with selective replication that didn’t include the profile documents, and then when a formula in the application used @GetProfileField a duplicate would be created and replicate out (since selective replication applies to the documents you receive, not those you send out), causing blank values for other users (as well as themselves). This is the problem Graham describes, but in fact it doesn’t destroy the values in the existing profile document – merely hides them. I blogged recently about a tool to see what profiles are in your application, so that you can easily find the new one and delete it. I think I might soon blog about a way to make sure it doesn’t happen in the first place, but I want to make sure there are no holes in it.
What to do about it depends on the reason you don’t want the profiles to replicate. Since you don’t want to discuss your reasons, it’s hard to make a recommendation, but a few choices are:
Let them replicate, but have different profiles for different servers using the username key of the profile (e.g. server := @If(@DbName[1]=“”; @Username; @DbName[1]); @GetProfileField(“ServerProfile”; “fieldname”; server) )
Use a Readers field in the profile document to disallow read access for servers other than the one it belongs on. This is a little tricky if there are local replicas, because the users would of course have to have access to all of them, and which one would you use in that case? Also, you would have to be careful when creating new replicas on servers to create a controlled-access profile on that server before letting anyone use the application, which would create an open-access profile through use of @GetProfileField, which in turn would replicate to other servers since they do have access to it.
Use a conventional document instead of a profile document. Selective replication applies to those.
I do, however, second Graham’s recommendation that it’s a little too easy for selective replications to get messed up, e.g. when creating new or local replicas, so I wouldn’t rely on that 100%.
Subject: RE: Prevent replication of profile documents
Thank you for your comprehensive response. I’m happy to have learnt that profile documents do always replicate and do not follow the selection formula.
Ruedi