Very Weird, Very Worrying

HCL Domino Domino Forum
1

This is very odd - and causing me a lot of stress, as I can’t explain it to the users, nor guarantee the system can be reliable.

We have two servers, one externally internet facing, and this replicates with an internal server in our lan.

We have a web database where clients post documents with feedback about our products and services.

The two servers replicate every 15 minutes.

The documents created on the external server replicate to the internal one, then a scheduled agent creates a workflow document in another database on the internal server.

Today, we suddenly found around half a dozen workflow documents which clearly related to activity several months ago. We checked the original documents in the web database, and these show a created date in the notes property tab of today.

We contacted the people who had submitted the documents and they confirmed they had done so last year.

Furthermore, there is a date field which gets set by the webquerysave agent on the web form which stores the date it ran - this shows today’s date.

I am completely baffled - it can’t be a re-appearing document issue caused by deletion stubs being purged between replications as the replication happens multiple times a day, plus no-one should be deleting documents.

I can’t see how corrupted views suddenly being fixed and displaying documents, as this wouldn’t explain the notes created date and the date field set by the webquerysave.

I am going to try and find an old backup tomorrow to load the web db from 2007 to see if these documents were there then.

Has anyone got any ideas what I can try next - I have to both explain and fix this otherwise the whole system is unreliable (we need to respond to these documents promptly)!!!

2

Subject: Very Weird, Very Worrying

Sorry, misiformation, the date field on the form is ‘computed when composed’ and has the value ‘@now’.

So how could this get corrupted?

I can’t believe there is any way documents could sit in limbo and not update for months - I am sure the server has been rebooted since October 2007, anyway!!!

3

Subject: RE: Very Weird, Very Worrying

I’m just gonna toss out some possibilities and let you decide if that could have caused your problem:

  1. Do people have the ability to copy and paste documents? If so, that might account for current versions of old docs. I always add code to my views to prevent people from pasting docs since there’s no need for them to do that anyway.

  2. Do people have local replicas of the databases in question? This could even be an old administrator’s machine, brought back online. If so and if the original documents were removed/archived form the database, someone replicating an old replica after the deletion stubs have been purged from the server replica (is it after 90 days?), those old docs would be replicated as new (although the date/time stamps might not agree).

  3. You mentioned fixing corrupted views. Depending on how your scheduled agent functions, if it reads from the view to get the documents to process, maybe that did cause the problem.

That’s all the crazy ideas I got. Hope that helps.

4

Subject: RE: Very Weird, Very Worrying

Thanks to everyone for their suggestions.Graham Richards :

In fact the computed-when-composed field does exist on these documents, plus the notes internal timestamp (@created) shows the Jan date.

Brian P.Mucha :

There are readers fields, but these haven’t changed - plus I don’t think that would explain the date field above, once visible, the document would show the created date as October, which it doesn’t.

Wing Mar :

They do have pasting - I am going to turn this off! However, I don’t think there is any compatible db they could paste from.

No local replicas, I am 95% certain - and nothing in the replication history other than the external server.

Corrupted views : a possibility, but again, wouldn’t the @created be correct, even if the document wasn’t showing in the view until now?

UPDATE

I now have a theory - I found some other forms with this data on the correct dates - what I suspect is someone in this organisation spotted them on the incorrect form this week and manually resubmitted them on the correct form so they would be passed through our workflow processes.

I am going to try and find out if this is it. If so, hours of stress wasted! (Plus the idea came to me when I eventually stopped working on the problem, as always!)

Again, thanks to everyone who responded.

5

Subject: RE: Very Weird, Very Worrying

When I hear about invisible documents I always think Readers fields first. Is Readers/Authors computed? Could you have somehow not had access until recently? Any design changes around those dates? Perhaps for a bit at that date the web form had the Readers field broken. Perhaps the DB was signed by an account that didn’t have access?

6

Subject: RE: Very Weird, Very Worrying

I would guess that that field is not being computed when the document is being created. Then, when you open it “today” to look at it on the client, it gets computed to “today”.

Computed-when-composed fields are slightly misnamed. They are really Computed-if-this-field-does-not-already-exist fields.

To check this, don’t open (or don’t save) the document, but look at it’s properties from the view. I’d be willing to bet that the field name in question does not exist in those documents.