>2. I would like to have put my views in another DBC instead of with the main dbc. The best solution would be to create all views programitically whenever the app starts. The problem is the performance. A view can have literally dozens of entries into a dbc file which tends to be slow.

OK, no big deal - don't do it too often :). Really, I'd prefer to have a main .dbc which could be regenerated anytime but would be almost read-only, and another one for views (wives?) only, where it wouldn't matter much if the properties of a view are changed often (for instance, changing the buffering scheme for a view to build temp indexes). This DBC could be packed or created from scratch whenever necessary. Sounds cute.

>3. The benefit is that you can mix and match applications in a lot simpler fashion.
>
>4. There is no performance issue at all (at least that I can find)

That's good news (though I expected it, but never had the time to try).

>5. The only real danger/pain I have found is if you put your data in one DBC and views in another you need to open the data DBC first and then the view DBC.

No big deal. Matter of fact, it sounds rather logical.