Re: Viewpoint Pro Brain-Damaged?

> kerry@kcbbs.gen.nz (Kerry Sainsbury) writes: > In article <48o0ht$eui@ionews.io.org>, haggarty@io.org (Dan Haggarty) wrote: > >A colleague is getting very frustrated with Viewpoint Pro 2.0. She finds > >that database changes render useless any related superViews that are defined > >for the reports that she's developing. > > Indeed SuperViews strike me as a bit naff too, and is for me one of > NewEra's turn-offs. > > Where, for example, is the "CREATE SUPERVIEW" or "ALTER SUPERVIEW" command? > Without these commands how on earth are we supposed to distribute changes > to SuperViews? Or distribute SuperViews at all. The SuperViews are defined in a set of tables in the database. I assume if you create a SuperView, unload these tables, create the same tables in another database and load the data the SuperViews will magically exist in the other database. But tools for this I have never seen. If you are clever enough you might even be able to update these tables after you have made changes to the database and perhaps your SuperViews will at least be accessible. Whether the reports/forms will still be usable I don't know. Does Informix expect us to create SuperViews and the reports/forms from scratch at every customer site? What if the customer should create their own SuperViews and reports/forms (unlikely at our customer sites but...). Then we come along with an update to the database (new tables and fields). When the customer finds out non of their reports/forms work, I know who gets the blame! And rightly so. We tell our customers to use any tool but ViewPoint. I pointed out all of this to Informix shortly after they realeased the first product using SuperViews. The fact that they have done nothing about it since shows they can't be very interested in this technology. SuperViews is a good idea, but Informix's implementation of them is not. Some points about how they should have worked: 1. They must still work without a hitch if the only change is new fields added to a table underlying a SuperView. 2. If a fieldname has been changed or a field removed that was part of a SuperView you should get a message and a user interface to make any changes needed to the SuperView as well as the report/forms definitions. 3. A tool to distribute SuperViews from one database (our development db) to other databases (our customer sites) must be included with ViewPoint Pro. If you do all changes to the database via ViewPoint Pro I think the SuperViews survive. That is hardly something we want to do. How do we keep track of these changes, document them, combine this with a database design tool+++ Again dear Informix. In database design and development you are excelent, but as soon as you make something with a user interface you are not. We have long since lost all interest in ViewPoint and all other usage of anything that relies on SuperViews. Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company