kspuea
asked on
"Cannot save bitmap to disk" problem
Hi all,
I have this Lotus Notes Client application to allow user to approve a form raised by staffs.
Staff can put a few attachments(not more than 1MB) in the form and submit to Manager.
So when the Manager approves the form, the system will generate another form (with the same data, ie. copy all items into another form and save it).
Now, one of the managers encountered this error --> "Cannot save bitmap to disk" when she approves the form (ie. saving the other form with the same data).
The application is in R5.0.12 design, and the server is using R5.0.12, but the manager is using Client R6.0.1.
Is that cause the problem?
And, I suspect it could be due to the application size too.
The current size of the application is 1868MB.
Could someone enlighten me on how to resolve this problem?
Thanks very much in advance!
~kspuea
I have this Lotus Notes Client application to allow user to approve a form raised by staffs.
Staff can put a few attachments(not more than 1MB) in the form and submit to Manager.
So when the Manager approves the form, the system will generate another form (with the same data, ie. copy all items into another form and save it).
Now, one of the managers encountered this error --> "Cannot save bitmap to disk" when she approves the form (ie. saving the other form with the same data).
The application is in R5.0.12 design, and the server is using R5.0.12, but the manager is using Client R6.0.1.
Is that cause the problem?
And, I suspect it could be due to the application size too.
The current size of the application is 1868MB.
Could someone enlighten me on how to resolve this problem?
Thanks very much in advance!
~kspuea
madheeswar
Size should not be a problem
Does it happen with certain type of attachemnts? Does it happen only with that particular manager or with anyone at random? If only with that manager, can she work with other documents without a hitch? Or in her case it always gets stuck? If this is just one case, it will need thorough This is more likely to be a client problem than a DB size problem. For that particulatr manager, please check if she has got proper permissions on the file system, enough free disk space on the system volume for swap space and swap file size is set to grow as per demand.
DB size on server is irrelevent from what you are saying. The Lotus Notes client is unable to perform an action it tries. Possibly, in that particular case, the data's in-memory image is too big to handle.
DB size on server is irrelevent from what you are saying. The Lotus Notes client is unable to perform an action it tries. Possibly, in that particular case, the data's in-memory image is too big to handle.
R6.0.1 isn't the best R6-client around. Can you upgrade, e.g. to 6.0.3?
ASKER
Hi RanjeetRain, madheeswar, sjef_bosman,
Thanks very much for your response.
Firstly, not only this manager has encountered this problem. I have 2 cases reported before too.
This manager has no problem to approve the other forms that submitted to her (those are with attachments as well). The attachment in this particular form is only 5K bytes. Thus, the size of attachment should not be a problem.
This manager is able to approve some forms which having larger attachments.
I just don't understand why she can't approve this form this time round.
I did a testing before, asked the user to remove the attachment, and submit the form again, and then the manager managed to approve the form without this error.
Please advise.
Thanks very much!
~kspuea
Thanks very much for your response.
Firstly, not only this manager has encountered this problem. I have 2 cases reported before too.
This manager has no problem to approve the other forms that submitted to her (those are with attachments as well). The attachment in this particular form is only 5K bytes. Thus, the size of attachment should not be a problem.
This manager is able to approve some forms which having larger attachments.
I just don't understand why she can't approve this form this time round.
I did a testing before, asked the user to remove the attachment, and submit the form again, and then the manager managed to approve the form without this error.
Please advise.
Thanks very much!
~kspuea
Just a wild guess! Do your users sometime create an embedded object rather than attachments? That is to say, will those documents having issues treat the content as attachments and not like an embedded objects? I have seen issues liek that in past.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
RanjeetRain,
My users attached usually, Word doc, or TXT file in the form, definitely not embedded objects.
HemanthaKumar,
Nope, I don't use any html in the RichText field. It's a Notes Client app, not web app.
As for changing platform, I don't it's the platform difference causes the problem. I have a manager having the same problem, and he is using R5.0.12, same version as the server.
qwaletee,
I agree with your points. I also suspect it's due to the attachment corruption.
Because I did a testing before, asking the user to submit a new form with the same attachments, and the manager has no problem to approve it.
Thanks very much!
~kspuea
My users attached usually, Word doc, or TXT file in the form, definitely not embedded objects.
HemanthaKumar,
Nope, I don't use any html in the RichText field. It's a Notes Client app, not web app.
As for changing platform, I don't it's the platform difference causes the problem. I have a manager having the same problem, and he is using R5.0.12, same version as the server.
qwaletee,
I agree with your points. I also suspect it's due to the attachment corruption.
Because I did a testing before, asking the user to submit a new form with the same attachments, and the manager has no problem to approve it.
Thanks very much!
~kspuea
ASKER
Hi all,
Finally, I got the cause of the problem.
I did a testing in R6 & R6.5, and proved that both versions have this problem.
It's not due to the attachment corruption.
Ok, let me explain how my application works:
I have a form in my application, which users raise and attach a few attachments in the form and submit to their approver.
So, when the approver opens the form, we will display another subform (which shows the attachments - computed subform), and hide all editable fields (including the attachment field). However, the attachment field in the computed subform can't show properly the attachments user had put in.
Hence, we changed the method of displaying the editable and computed RichText fields. We put all editable fields into a subform (ie. take out from the main form). And in the main form, embed a subform based on formula, so at each time, only 1 subform is displayed (ie. 1 RichText field is displayed). Then it works fine.
Does someone encounter this problem in R6 or R6.5?
Thanks very much!
~kspuea
Finally, I got the cause of the problem.
I did a testing in R6 & R6.5, and proved that both versions have this problem.
It's not due to the attachment corruption.
Ok, let me explain how my application works:
I have a form in my application, which users raise and attach a few attachments in the form and submit to their approver.
So, when the approver opens the form, we will display another subform (which shows the attachments - computed subform), and hide all editable fields (including the attachment field). However, the attachment field in the computed subform can't show properly the attachments user had put in.
Hence, we changed the method of displaying the editable and computed RichText fields. We put all editable fields into a subform (ie. take out from the main form). And in the main form, embed a subform based on formula, so at each time, only 1 subform is displayed (ie. 1 RichText field is displayed). Then it works fine.
Does someone encounter this problem in R6 or R6.5?
Thanks very much!
~kspuea
So, it was rich text on a subform tht was embedded in another subform?
ASKER
Not really, it was rich text on a subform that refers to the rich text embedded in another form.
And I have tested in R6.5, if you are using a Computed Rich Text field in a subform to refer to another hidden (and editable) Rich Text field in the main form, then you will have this problem.
And I have tested in R6.5, if you are using a Computed Rich Text field in a subform to refer to another hidden (and editable) Rich Text field in the main form, then you will have this problem.
ASKER
Strange thing is, the same method works fine in R5.0.12.