View index - any improvement in version 7

I tried to create less view , but I found out that having view with less documents selected tend to give faster view index refreshed than having one view with many documents selected.

Or should I have many databases instead? and use picklist to select data from different database? I have not test it on client, as my databases can only reside on local , as I design it in such a way, where it still be usable should my user travel overseas at places where internet connection is poor.

Problem is, when I made copy, it only runs around 300mb, but with view index being build up , it expands up to 11 GB?

Since each of my database only runs up to 15 months, and it is already the 13mths now, I foresee it will grows up to 15GB by month 15.

What I have done thus far is to delete and move non-essential data to another database.

Problem is that the database did not get shrink due to how it is designed, so I have to make copy and refreshed back relevant view independently.

I still not able to learn how to use data connection or sql as I can’t find much help on it thus far, even there are not many books have been written about it.

any help is greatly appreciated.

Regards

will.

Subject: View index - any improvement in version 7

Completely rebuilding a large view might take a long time, but I doubt that adding a few documents has a great impact on performance. you should only rebuild indexes on views that are hardly visited or when they get corrupted somehow.

Subject: View index - any improvement in version 7

I’ve only seen such a view index bloat in an application we tested, where in each view, almost every column was sortable.

If that’s the case in your db, you’ll have to delete the offending views and recreate them, making only the columns manually sortable that really need to be (the least possible). Just removing the sortable option will not get rid of the index size.

HTH

Patrick