Changing render= on link causes attachment deletion

HCL Domino Domino Forum
1

  • I say this is DDE, but that’s not cast in stone. It’s simply a change in DDE that causes the issue to appear, so I say the product area is DDE. Originally I even thought that, but after today I’m not so convinced of it.

  • This is long. It contains information that took place over a long period of time, and there’s lots of it. If it’s too much I apologize, but it wouldn’t be complete if I omitted much of it.

  • I have a Form with one richtext field on it, and that field contains one attachment, on a pre-existing document imported from another system. There are other text and date fields on it, but only a handful. It’s fairly simple as Forms go, and it’s been used in an R6 application for years.

  • Now I am web-enabling it, so I have an XPage that uses that Form. This XPage was originally a complex mix of facets and custom controls, but since I’ve been seeing attachments get deleted I’ve stripped most of that away. It currently has two custom controls on it, one is a navigator and the other is a debug dump of scoped variables.

  • The XPage of course has one download control and one upload control on it, bound to the same field, and a considerable amount of JS, both client and server side, both on the page “itself” and in data source events. Originally all the navigator links had complex stuff on them, but now every single one is identical. They set one sessionScope variable to indicate what button was pressed, they do a saveDocument, and they redirect to the caller’s page that’s stored in a sessionScope variable. Well nigh trivial compared to what used to happen.

  • When this first happened I put in a PMR on it, and Austin (most excellent support dude) discovered that a simpler XPage consisting of just the Form fields, nothing else, would commit to the database without deleting the attachment already present. So I copied his XPage into my development template and slowly added in pieces until at last I had them all in … except one. That one wasn’t critical to development, so I left it alone.

  • That one was the render= attributes on the navigator custom control links. The navigator custom control is a set of links decorated with CSS to look like buttons, from Dec’s XPages blog, almost verbatim. I noticed time and again while vetting Austin’s simpler XPage to contain my functionality, that updating these attributes would break one of two things:

  1. Attached files would go back to being deleted again.

  2. Server-side actions, simple or JS, would no longer function.

It wasn’t always render= on the links that caused effect 2, either. Often simply editing any aspect of any link would cause server-side actions for all of the links but one, always Save for some reason, to stop working. But I persisted, and started from Austin’s XPage many times, until all was in place except render=, and I left it at that.

  • Last night it was working pretty darned well, so I did a full system backup. This system has a server on the host OS and DDE in a VM on that host, to isolate it from the server. There is a second VM I run to get email, so Outlook can’t directly infect the primary OS. This VM also has my half-dozen R-Prior installs on it, because one never knows when an R-Prior Client or Designer will be necessary. I’ve been using this setup about eight months now with no apparent issues. In fact when I moved DDE to its own little world a great number of issues completely vanished. Sadly so did another gig of RAM. (silly grin)

  • First thing this morning I thought “I have a backup”, so I updated the render= attributes on the links (decorated to look like buttons). ALL server-side actions were broken, including the Save link. So I recovered the template from the backup. This fixed server-side actions, but the first thing I noticed once they were working is that attachments were back to being deleted again. I couldn’t discover this deletion effect until server-side actions worked, since is a server-side action, and if doesn’t run, nothing gets corrupted. (grin)

  • I spent the entire day fiddling with this, to no avail. I tried:

  1. Recovering the template from backup (this fixed server-side actions)

  2. Recovering the template from backup (again), deleting the application from the server, and recreating a new application from that template.

  3. Recovering the VM that runs DDE from the backup.

  4. Manually copying design from DDE to the new application from step 2 and building in the application, not the template.

  5. Creating new XPage and Custom Controls and pasting the code from Source.

  6. Numerous other little things I didn’t log in my journal.

  • I finally went back to Austin’s XPage, the one I used to fix the problem before, and lo and behold, it saves without deleting attachments, just like it always has.

  • Note that once the XPage starts deleting the attachment on save I have never found a way to prevent it from doing so. Recovering the template from backup put the code where it was before the backup was made, yet that XPage continued (and still continues) to delete attachments. Same with recovering the entire VM. This is why I’m not convinced it’s DDE any longer … when the VM was recovered DDE was utterly reset to last night, when it worked, yet it doesn’t. The only constant there is the server.

  • But Austin’s XPage continues to work, even in the (still) corrupted application, which I find to be more than passing strange if the server is the issue, particularly since I started with Austin’s XPage to get the corruption I see now.

  • The only way I know to fix this, and it’s what I’m doing again, is to start from Austin’s working XPage, which uses the exact same Form mine does, and start slowly adding in my functionality until I have it back again, except for the render= attributes. I’m doing this by way of attempting to create a sample application that exhibits this corruption for Lotus. Hopefully in the process I will have my application back in working order, but again sans proper rendering on the links.

  • Austin has a sample application with one corrupted and his good XPage in it. He thinks this may be a corruption of “the database shell on the file system”. I take that to mean the database structure is compromised, but it has to be in a way that consistency check doesn’t detect, and that doesn’t cause any manner of error or even subtle indication (other than this XPage issue) that something is amiss. Not saying Austin is wrong, I’m saying I don’t know how to prove he’s right.

  • Lotus suggested I post this here, so I did. If anyone has even a glimmer of a hint of something that pays lip service to being a clue I’d be happy to hear about it, and try it.

Thanks for your time…