Replication in LN 8.5.1

Is there anything new in this release that we can make use of in Notes Applications to avoid all sorts of issues related to deleted documents which re-appear on the Server?
Who is Participating?
Sjef BosmanConnect With a Mentor Groupware ConsultantCommented:
> Where in the world are you guys based:
RTFP... It's all in our profiles (F & NL). You' say you're in Australia  (guessing you're not born there), but that's not in your profile.

As for XPages: very interesting stuff, but expensive to start with indeed: a developer needs to acquire 50% new Notes stuff, and if you want to redo the whole application, it's a complete and total change. Luckily, you can continue to use the old Notes elements, as usual Notes and Domino stay compatible with older developments. On the other hand, a complete XPages-based web-application can be a PITA to develop. Literally *nothing* works the way you were used to. Luckily, when you get the hang of it, it works nicely and sometimes even 10 times faster!

Reappearing deleted documents are part of life with Domino, as are replication or save conflicts, corrupt databases and problems with the Out-of-Office functionality. Learn to live with them, and what's more important: educate your users! Ask them not to start a Notes client that has been switched off for a few months.
Probably not the answer you are looking for but...
Consolodate your servers and rebuild your apps with XPages. XPages is pretty powerful and will allow you to slowly move your users away from the Notes client to Web Browsers without changing the look and feel of apps. Apps built with XPages are faster and this will cut your costs in server hardware, licences, backup and allow for easy transition to mobile devices etc. etc. etc.
Obviously this is dependant on how many users, number of concurrent users, where they are located and various other things.
Worth a feasibility study, but not a quick fix I'm afraid :-(
Sjef BosmanGroupware ConsultantCommented:

But you might upgrade rather soon to 8.5.2, for 8.5.1 isn't the best of releases.

Usually, when documents reappear in a database, it's most likely that someone with a fairly old replica just switched on his Notes, or an old server was reactivated. What happens then is that modifications between the date Notes was stopped and the date mentioned as the replica's deletion stub retention date are considered new documents. The reason is that there are no deletion stubs in the recent database to refuse those older documents.

In the Replication Options for the database, what is "remove documents not modified in the last (days)" set to?
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

As an alternative: have you considered not to allow any deletions and start offering soft deletions only?
I haven't tried this for surch purposes, but it should work:

Soft deleted docs would remain in your database, but you should be able to exclude them from any view or agents' search. You should even be able to remove most fields (except the deletion mark) to save space.
Since the soft deleted documents remain in the database, they'd continue to replicate. There would be no deletions stubs left for the system to remove (re: Sjef's comment), so document can't get reintroduced!
Make sure the system merges replication conflicts to protect the deletion marks. Fields might replicate back, but the soft deletion mark would still be there, keeping you out of trouble!

Downside: it would require some rework on your current apps!
Sjef BosmanGroupware ConsultantCommented:
Interesting thought...

One more downside argument:
- the database will only grow, soft-deleted documents aren't deleted, attachments are kept as well

The same can be achieved by setting the "removed documents" value to a much higher number, plus you have the advantage that the document and attachments are indeed removed.

@CRAK. A related thought: if there are multiple replicas around of this database, what would happen if one of the replicas were to have "remove documents not modified in the last" 365 days? If a document copied back in hits that database, will it be removed and will a new deletion stub be replicated to other databases, resulting in the deletion of the document everywhere? It's just a thought, and it probably won't work the way I described.
@Sjef: the question is: would that still be possible?
If so, we'd end up replicating the document back into the database, as soon as its deletions stub gets removed. Not sure if it would get re-deleted for a few months straight away.

Important is to know that those replicas would not be allowed to replicate their deletions to other replicas if the ACL is set properly.
Sjef BosmanGroupware ConsultantCommented:
@CRAK: I don't understand... It's still early, them little grey cells need some time to warm up.

Maybe my suggestion wasn't clear enough. I'll rephrase a little:

"... what would happen if only one of the replicas were to have "remove documents not modified in the last" 365 days, and the others remain set to the default of 90 days?"
shals0628Author Commented:
@Sam654 - Thanks for the information, am yet to do my homework on XPages. :-(
@Sjef - Currently we are using Rel 8.5.1 - and would like to know if there any new features added to the 'Replication' in this Release. In the application currently the Replication has been disabled. Need to enable the Replication, just checking all the new features that are available in this Release related to Replication. How far, the setting in the ACL for 'Replicate or copy documents' help us in controlling the Replication?

For the workaround related to 'deleted documents' reappearing - I plan to write a code in Db open event to check for the dates if user has not replicated for more than 30 days, it should not allow replication or delete the local replica. It should be possible right?
Sjef BosmanGroupware ConsultantCommented:
AFAIK no new features...

Not replicated? Isn't replication done automatically? I hope it's not a manual activation.
I don't think that can be done: IF we manage to get hold of a list of successful (!!!) replications (no failed attempts), how do we know that this replication was done with an up-to-date machine?
Anyone could download a trial domino installation, replicate his/her local replica to this new server and continue to replicate with that server only for the next couple of months.

@Sjef: I.M.O. the deletion stub would get reintroduced to the 90 days boxes and get discarded there again, until the 365 days box drops the stub.
The problem is: if some "bright" user restores his 500 day (> 1.33 * 365) old local backup to his new laptop and start replicating, he'd reintroduce docs!
Increasing 365 days to e.g. 3 years would reduce the risk, but if that backup is restored after 4 years....
shals0628Author Commented:
@Sjef - yes, we use scheduled replication. However, the issue related to deleted document still exists.
@Sam654 - Can you give me more information or help on how XPages can be used to avoid this Replication issue?
Consolidate your servers. If you have 10 servers with 10 licences, buy just one (probably a bit bigger) server and only have one licence (although licences are done on processing power too).
By telling you to use XPages, I'm really saying to rebuild the databases using the new XPages technology and put them on your one consolidated server. Allow people to connect using Notes client or web browser, using XPages it not too difficult to make the user interfaces look the very similar, so you can start moving your users off using Notes clients and start getting them to use web browsers to access these apps <whisper> it's the future... ;-) and it's makes the apps much better.
There are all sorts of cost benefits.
It's not a small project though, don't be disillusioned I'm talking rebuild your apps!
Replication annoys the hell out of me, especially when we go down to local replicas (feeling pain just thinking about it!) it's not my area and when I come across it, I give it to one of my other guys who seem to not mind it to deal with.
So like I said before, worth a feasibility study. If you're in or near Sydney Australia, go to my profile and use the hire me thing to contact me and I'll get one of my guys to come on site and do some analysis.

Mine is the long term solution and will take a while to implement and the others solutions (CRAK and Sjef) are ones that you can investigate right now. You you've not got the expertise inhouse, I suggest getting help in, but maybe that's just me due to not been keen on complicated replication issues.

@Sjef & @CRAK - Where in the world are you guys based so I can refer people to you in real life if required?

Oh, just re-read your question directed to me. My solution would help as there would be no replication as you'd only have one server. A feasibility is required as your environment might not have the infrustructure to support that, eg. permanent Internet connections as with any web based apps etc.
shals0628Author Commented:
There is no complete solution other than to educate the end users.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.