This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


Jun 1, 2017, 2:01 PM
24 Posts
topic has been resolvedResolved

Bug in site deletion(Resource Reservation db)

  • Category: Calendar
  • Platform: All Platforms
  • Release: 9.0.1
  • Role: Administrator
  • Tags:
  • Replies: 2

Interesting bug found in Resource Reservations template from version 7 til version 9


The database script function QueryDocumentDelete and the script beneath the “Delete Site” button produce both an error the following scenario.

Assume you have created a site which name contains a stressed characters like letter à, é, è, …
Let’s now imagine you first misspelled the site name: “Musèe” instead of “Musée”.
Some resources have been created and numerous room reservations are already recorded in the database.

When asked to correct the misspelled site name, the first thought is to create a new site, to create new ressources referring to the new site and to prevent booking further reservation for the old site. The old site will be deleted  when all reservations will become outdated.

Then, problem come:
“You cannot delete this Site Profile because there are still rooms, resources or online meeting places referencing this site in the Address Book.  You need to delete the rooms, resources or online meeting places using the Delete action provided in the resource form before deleting this site profile.”

A look in the code shows the problem.
There is a call - in fact more than one - to a @DbLookup formula:
RoomLookup=Evaluate (|@IsError(@DbLookup("":"NoCache";Server:"names.nsf";"($Rooms)";Site;1))|, note)

So deleting the “Musèe” site will always fail as @DbLookup will make no difference between “Musée”, “Musée” or even “Musee”.

It should be more reliable to use a GetDocumentByKey(key,True) against a NotesView object…
This problem doesn’t seem to have occurred many times as IBM didn’t notice (or didn’t do) anything since Domino 7.

Jun 13, 2017, 8:33 PM
196 Posts
Here is a workaround

In this situation, the workaround is to move the site from Musèe to Museum, and then back to Musée.  I would move the rooms associated with Musèe to Museum, and then, after the dust has settled, I would move the rooms from Museum to Musée. Museum as a site name is only needed to get around the limitation of Musèe and Musée being seen as the same thing.

Jun 14, 2017, 12:13 PM
24 Posts
Problem was already fixed

Anyway, thanks for the hint.

Methodology used was about the one you described.


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal