|
|
I'd just like to be able to compact a design template and have it purge all now-unused fields from the e.g. column list
You know how it is, you created name, name_1 and name_2, saved the form, renamed the fields to what you want, but these three fields still
|
|
|
When a server that is a member of a cluster performs consistency checks on a database, or compacts a database, it should automatically mark the database as Out of Service in the Cluster Database Directory for the duration of the operation.
(In the case of compact, it will only happen during
|
|
|
Instead of having to resort to issuing console commands to get the job done (load compact -daos on|off db.nsf)
|
|
|
For my understanding IBM looks to less on Notes Client Installation on a Terminal Server. We have about 10.000 users. And there local files (bookmark, names, autosave, desktop, etc.) are stored on a files server. Some users have bookmark or autosave files up to 100 MB each. It grows from
|
|
|
It would be nice if there were a desktop poilcy that woiuld perform regular file maintenace on Lotus Notes databases. I have been using it since version 4.6.5 and we have many users who have been through 3 -4 upgrades. Unless I touch their workstation and run manual compacts, fixups
|
|
|
The compact task is currently unable to compact those databases in use by IMAP users (especially those users who leave their IMAP clients running 24x7). The compact task flags the database as in-use. Could another parameter be added to compact (in addition to the in place or copy modes) that tells compact to
|
|
|
Why not permit a hard quota on an NSF, and make that it's *starting* size as well, so no new OS-level allocation has to occur? I can think of many cases where I'd like to say "make this NSF 100MB, no matter what data is in it. Just pre-allocate the
|
|
|
In relation to the defragmentation idea, allow for compact -c to actually ADD white space. This can help to ensure that the database can have some "room for growth" and alleviate some disk concerns.
|
|
|
Add columns on Files tab view for the following in the Admin client:
number of documents in a database (instead of having to look at database properties) - helpful when trying to resolve cluster replication issues
date of last compact - (would be great to see when a database last had a
|
|
|
We have this nice shiny new progress indicator, yet local tasks, such as Compact don't display on it, however other local tasks such as Refresh Design do.
|
|
|
Many organisations rely on local replicas. Many of those same organisations also employ quotas to control mail file size. In many cases the notes client doesn't remove indexes when compacting databases. Hence with repeated compacts and some people having hundreds of folders the index grows to a point where with
|
|
|
Create a small, end-user friendly applciation to essentially run all of the "n*.exe" programs in the Notes program folder.
In particular, the abiltiy to run "the big three" maintenance applications against one's local databases:
(1) Fixup
(2) Compact
(3) Updall
If you want to go for broke, add a scheduling utility (think: anti-virus and anti-spyware
|
|
|
I would like to have the ability to compact all local databases at once. It would be great if this could be a toolbar button or even a menu option. I've written Lotusscript code that does this, since Notes was built with the idea of local/disconnected use, this capability should
|
|
|
When initiating a compact/fixup/updall command it would be great to get an idea if the task completed successfully, or was interrupted, had errors, or even how far along it was. Watching the console and scanning through millions of lines to look the status is well, painful - especially if it's
|
|
|
It's great that you can reduce peoples access to Editor and provide most of the functinality that they need (enable OOO, grant access) but in doing so, it prevents usrs from being able to compact their mail file.
|
|
|
From version 6.0 there exists the database property "Use LZ1 compression for attachments" which can compress attachments better then the standart "Huffman" method. However this property is by default not enabled and it also only affects attachments which are created after it has been enabled (or disabled). This means that
|
|
|
Local replicas tend to grow in size and they often contain a lot of free space. Right now it is only possible to compact every database separately through the "Database properties".
We need a function on the replicator page which would compact ALL existing local databases at once. (And maybe scheduled
|