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


~Bella Frofanalyetsi
Apr 10, 2015, 2:17 PM
32 Posts
topic has been resolvedResolved

@dblookup from another database vs current

  • Category: Performance
  • Platform: Windows
  • Release: 9.0.1
  • Role: Developer
  • Tags: Performance,@dblookup,database
  • Replies: 1

Hi,

I have a huge database with lots of Forms and views and around 30 GB of size.

My database contains essential design elements in addition to my keywords. I have lots of keywords views that I would like to move to a separate database to relief my main database, in terms of size and views indexing.
knowing that my keywords data is fixed and doesn't change so no need for the indexer task to run through its views.

To achieve this, I will modify all my @picklist and @dblookup and other views retrieval in LotusScript. This looks very good so far, my concern is about the performance of the @dblookup when it uses the keywords database on the same server, instead of accessing keywords views from the same database.

Any idea on the performance?

Thank you,
Samer

~Autumn Kijipymanakol
Apr 10, 2015, 4:38 PM
31 Posts
It might depend on how you reach the keyword DB

I have used this sort of thing in the past and believe that this is a good design practice as well.

I believe from what I have read and seen that opening the DB via the replicaID is faster than opening it via the path, and that would make sense. I create a profile document where I store the replicaIDs of the various DBs that I want to access. This makes maintenance much easier if you ever need to change the RepID  and the values are cached so there is no server trip once it is read.

Doing it this way should actually result in some performance improvement. Whether it is a measurable amount I don't know, but maintenance should be easier.


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