Here’s the scenario:The customer’s database is intended to store lots and lots of files within richtext fields. Some have gigabytes of data in the field, and commonly in the tens and even hundreds of meg. (I know that’s not what Notes is inteded to do, but sadly that’s out of my control.)
The result is that some documents are developing the rich text paragraph issue – a document can’t be reopened because the RT is considered corrupt as there’s no paragraph break in the RT field. So now it’s time for a remediation of the issue.
Solutions:
Programatically go through all documents with either (a) a large volume of data or (b) a large quantity of embedded files and insert newlines into the RT field.
Manually go through any potentially offending documents and make manual corrections. There’s probably a couple hundred that need this. Then provide customer instructions about the situation and make it their responsibility.
2.1 I’d also provide a programmatic method for making the corrections should it occur/when it occurs again in the future.
Any other ideas that should be on the table? Other thoughts on pracitcality?
Not sure if this would resolve your problem, but here is something that did in a similar situation where there were a lot of attachments and this generated a very slow response to opening and saving the document, plus replication was very slow.
We created a parent document that basically held the Meta-Data for the document (ie all the things that controlled it’s processing) then we created one or more children that contained the very large attachment (some very large image files). Generally once the child document was created there was very little change made to the Child Document. If new Images were generated they woul generally go into a new Child. However, there were lots of changes made to the Meta-Data in the parent.
So if the parent document is opened and say a date field was changed this would happen very quickly because there was no need to transmit the many MB of images. The Images were only opened when necessary. This change also means that when there was a change to the parent document there was no need to replicate all of the children because they were not changed.
To improve performance even more store the image documents in a separate DB with just one Single Category view that is embedded into the parent document with the Category being the Parent ID. The end user could then click on any one of the image documents in the embedded view and obviously when they did the system had to bring down all of the images in that Child Document and that might take some time. The over-all response time of this setup is really significant and can be in an order of Magnitude faster. Plus replication was cut to a fraction.
I know this does not specifically relate to your page break problem, but it does turn a kludge slow Notes Dog into a pretty responsive system.
Subject: RE: *You might just be on the edge of disaster!
I would split the documents which have multiple file attachments into seperate documents with fewer attachments. They could be response documents, or otherwise programmatically linked together.
This is exactly something we would like to do and have it automatically occur for future database entries. We want the user to be able to select multiple files to save as attachments and have Notes/Domino split the attachments up into multiple Notes Docs upon saving.
Does anyone have an idea of the best direction in accomplishing this programmatically.