Spanky's Place :: Removing fields from a document without changing timestamp or last author

Technical question for all:

I'm working on an existing Domino application with some 94,000+ documents. The main form includes a standard web header subform, on which there is a COMPUTED (not computed for display) field called "Query_String_Decoded".

(Note: I also posted this on LDD.)

This field is populated with the CGI value of QUERY_STRING_DECODED when either:

the document is created for the first time:

.....nsf/MAIN_FORM?OpenDocument&QueryStringInfo
or the document is edited:

...nsf/0/UNID?EditDocument&QueryStringInfo

and then it is saved when the document is saved.

Which means, of course, that it is stored on the document. This is causing all kinds of difficulties when attempting work with the document in Read Mode:

...nsf/0/UNID?OpenDocument&QueryStringInfo

because it takes precedence over the actual Query_String_Decoded value.

I have rectified the design issue, but I'm still left with 94,000+ documents with this field stored on the document. I can put together an agent that will remove the offending field from the documents without any problem; except that the timestamp and last author ($Revisions and $UpdatedBy) fields will also be changed by my agent -which is something I don't want.

Does anybody know of some way for me (perhaps something like using a NotesDocumentCollection.StampAll method) to do this easily, or am I essentially screwed?

Thanks all,

-Devin.

Wowsers! A Tag Cloud!

Comments

1 - NotesDocumentCollection.StampAll won't cut it, since it also changes Modified and UpdatedBy information. We have solved that problem by before hand creating a field for that infomation. Ie. using Field Authors with value @Creator, Editor with @Name, etc. However you might give replication a shot. First create replica of the original database, but in Replication formula, do not replicate Query_String_Decoded. Then create a new replica of that, but remove the previous replication formula. Then use that instead of the original database. You also need to change that Query_String_Decoded field to Computed for display (and take care of all things that relate to that field).

I am not sure if it'll work, but it sounds easier than trying to fix the database with a hex editor. ;)

Posted by Mika Selin At 12:21:38 PM On 04/02/2007 | - Website - |

2 - If you have to go down the Hex Editor route I'd like to recommend ScanEx from Ytria, I think it will do exactly what you need and you can 'rent' the product for a few days instead of having to get purchasing budget. Very Handy.

Posted by Declan Lynch At 12:31:00 PM On 04/02/2007 | - Website - |

3 - Make that ScanEZ not ScanEx

Posted by Declan Lynch At 12:32:58 PM On 04/02/2007 | - Website - |

4 - Thanks Dec.
Truth be told, I REALLY don't want to hand-edit 94K docs.

Mika -your idea has merit; I may consider going that route.

I'm also considering cracking open the CAPI -I wonder if I can manually set the values of the $Revisions and $UpdatedBy fields using the CAPI? If I can control the values there, then I could simply loop through all the docs, and for each one grab the values for the fields, kill the Query_String_Decoded field, save the doc, and then set the values to what they were before the change. Of course I'd then save the doc, but I don't know if doing it within the CAPI would set those fields or not.

More to ponder...

-Devin.

Posted by Devin Olson At 01:09:12 PM On 04/02/2007 | - Website - |

5 - I believe that any "save" will update those fields, no matter what tool you use to perform the save (e.g. API, DXL). I never thought of hex editing, but that - in theory - is at least possible. It would be ugly, though, for 94000 of them. heh.

I suggest re-redesigning your app. Your response on Notes.net says that the issue with updating these two fields is that they're used for measuring performance of employees. Simply put, take out the reliance on those two fields. Put their data somewhere else. Then rely on the various querysave events to update those new fields. While you're at it, put in an 'admin' back door so that docs can be updated in the future WITHOUT updating those fields, by you or someone else if you set a particular flag (@Env works well for that). Make sure your "admin" routine sets an audit trail, then nobody should be worried about the admin tweaking someone's performance results (bribery concerns?).

Posted by Rob McDonagh At 01:27:52 PM On 04/02/2007 | - Website - |

6 - Devin, ScanEZ will allow you to select multiple docs to perform the field removal from. It won't be by hand.

Posted by Declan Lynch At 02:16:09 PM On 04/03/2007 | - Website - |

7 - Hi,

with interest I have read your blog entry and have consulted our "Notes Gurus".

Any change done, by whoever and whatever, will change the $UpdatedBy... there is no getaway from this one... Even "cracking open the CAPI" as I was told cannot help (We have a lot of experience in this area).

Anyway if you are interested in trying scanEZ - shoot me a mail and I will generate a temporary full license for you. But remember: It will change the $UpdatedBy

Best
AndrÃ©

Posted by Andre At 03:16:26 PM On 04/03/2007 | - Website - |

8 - @Andre. I was checking out your site yesterday (looking into ScanEZ) and was wondering if it would work. Thanks for clearing up my questions.

Thanks,
-Devin.

Posted by Devin Olson At 06:02:43 AM On 04/04/2007 | - Website - |