Fixes and limitations for Manifest db
The dev version of the Manifest db apparently wasn't tested, although I assumed it had been, so when asked for the live one I went ahead and built it, but obvious problems emerged immediately. The heart of the problem is the attempt to include custom fields. The custom fields code is intimately tied to the original AdaptiveDB structure, and has never been written to be portable and generalized (no other project has ever needed it). In order to work for another db, a special view has to be created, and the code as it is also depends on one specific field in the original documents table (the docTypes field), which doesn't exist in the new db. It would be possible to port the code, but I don't have the time to do it right now, and I'm also not sure whether it really is needed in this new db, given that it's very quick to add new fields on request using the existing setup, so for the moment I'm removing the custom fields from the Manifest db. It now seems to be working (at least the dev version I've tested is working -- waiting for feedback on the live one because I don't want to enter test data into it). I've also written the standard live-to-dev copy script for future bugfixing.
In the long run, it would be possible to make the custom field code more portable, but no other projects have required it apart from JW's so far, so I'm reluctant. It's also a serious performance bottleneck, especially when it comes to building large spreadsheets, so it may be a bit of a developmental dead end.