Re: IDS New Feature Requests

I'm assuming the reason for this request is so that the view definition is not lost when an underlying table is dropped. Seems fair enough. On that note you'd have similar issues with foreign keys that reference the table being dropped. This would seem controversial but doing the same with those constraints would be nice, leave them but in an invalidated state. This would make unload/drop/rebuild/reloads much less cumbersome. An alternative might be to include DDL for referencing constraints when dbschema -d db -t tb is executed, probably commented out since they may not be required. Maybe an even better option would be another dbschema flag that would dump DDL for all database objects that reference the given table. --- hariog@yahoo.com wrote: > Hi David, > > Just a thought, pl. include in the list if ok: > > Feature > When > Whom > > Do not drop views if parent table 14-12-2005 > hariog@yahoo.com > has been dropped. Just invalidate > it. Also, command to validate and > list such views. > > Thanks. sending to informix-list

Hmm.. not to get down on this but now that Informix has TRUNCATE TABLE. The drop/rebuild/reload could now be done by DISABLE INDEXES (OR DROP THEM)? TRUNCATE TABLE; ALTER TABLE <columns>; ALTER TABLE x NEXT SIZE NNN; ALTER FRAGMENT ON TABLE x INIT IN ...ENABLE INDEXES (SHOULD BE QUICK).. LOAD TABLE. ENABLE INDEXES (OR RECREATE THEM) The thing I would like to be able to do is to be able to alter the size of the first extent once the table has been truncated. Since the table is never dropped the views, triggers, synonyms, constraints etc never get invalidated.

DL Redden wrote: > I'm assuming the reason for this request is so that > the view definition is not lost when an underlying > table is dropped. Seems fair enough. > > On that note you'd have similar issues with foreign > keys that reference the table being dropped. This > would seem controversial but doing the same with those > constraints would be nice, leave them but in an > invalidated state. This would make > unload/drop/rebuild/reloads much less cumbersome. > > An alternative might be to include DDL for referencing > constraints when dbschema -d db -t tb is executed, > probably commented out since they may not be required. > > > Maybe an even better option would be another dbschema > flag that would dump DDL for all database objects that > reference the given table. myschema -F -d <databasename> -t <tablename> .... Only thing it does not do is report stored procedures referencing the table. Hmm, sounds like another entry for my todo list... Art S. Kagel