Alastair, Unfortunately when you do a database UNLOAD/BACKUP the order in which views are unload doesn't follow an acceptable patten to prevent your problem under all circumstances. They aren't unloaded in the "SYS_TABLE_ID" of SYS_TABLES order or in the "SYS_TABLE_NAME" order of SYS_TABLES it appears that they are unload in the order the view appears in SYS_VIEWS. The order that views in SYS_VIEWS appear to be a function of SYS_TABLE_ID from an initial load of the VIEWS which is in SYS_TABLE_ID order. However if you delete and re-create VIEWS the order seems that it is as if the views are appended to SYS_VIEWS with any re-created views dropped from original position.
Until you raised this question I hadn't really considered the question of how view are unloaded. In my Main Address database I do have some views which are "views of views". Now I will have to reconsider my strategy defining and re-defining dependent views. I had been adopting a strategy of having the name of the base view beginning with "A" in the belief that they would be unloading before that views that use them. now it seems that if I change (read DROP VIEW, then CREATE VIEW ) using another view it may be necessary to drop the base view and all using views then recreate them in order to keep them in proper order. I would like to poll the list. Should RBASE. 1. Keep the VIEW unload/reload method as is 2. Unload VIEW in view name order as defined by SYS_TABLE_NAME of SYS_TABLES where SYS_TABLE_TYPE = 'VIEW' 3. some other method. >From the responses on the list we can determine if the development group need an "Enhancement" request. My Personal preference would be for option 2 above. thus the developer could control the unload order through the naming convention adopted. othewise the syntax documentation needs enhancement to describe the order in which views are unloaded and how to deal with creating/dropping/re-creating views of views so that an UNLOAD/RELOAD (BACKUP/RESTORE) of a database will properly recreate VIEW under all conditions. -- Jim Bentley American Celiac Society [EMAIL PROTECTED] - email (973) 776-3900 x5029 - voicemail/fax ---- "Alastair Burr" <[EMAIL PROTECTED]> wrote: > I needed to backup up and then restore a database this > afternoon and was surprised to get an error message about > a table/view not being defined. I had just run AutoChk > with no errors so I compared my original database that > I had renamed with the restored version and discovered > the reason: > > The view that failed did so because a view it used had > been backed up after it had - thus it failed to find a > constituent part of its definition! > > I'm not aware of tables ever giving this sort of problem > (with constraints) but - perhaps - it's something to be > aware of. > > My other point relates to the reason for the backup and > restore which was to try and remove a stored layout for > (another) view which seemed to refuse to go away: > > I saved the view from the QBE screen after running a browse > command at the R:>. I then browsed it again when I (recklessly!) > locked one column in the first position. I then changed > the column selection and sequence in QBE, saved it, and > browsed it. I probably should have unlocked the column > first but I didn't. > > Not unsurprisingly, the locked column had not moved and > when I tried to remove the lock R:Base crashed - telling > me that the R:> prompt window could not be closed in its > current state - great, I no longer had an R:> prompt window! > I had to forcibly close RBW. > > To cut a (very) long (and frustrating) story short, I ended > up recreating the original version of the view, unlocking > the column, deleting the view and recreating the version > that I wanted - after I had repeatedly edited Sys_Layouts > and deleted all references to the view; deleted and re-created > the view again; run AutoChk again; run BackUp, edited the > backup file to ensure no references to the view in the > Sys_Layouts section, then restored again. Still the locked > column was locked and every time I tried to unlock it RBW > crashed. Eventually, I removed all the load Sys_Layout > block from the backup and restored that and then re-created > the original version of the view... > > Surely, when restoring from a backup file, if there is > no reference to a layout it - the layout - cannot get restored? > I doubt that it's relevant, but what was the problematical > view is based on another view - just re-arranging the columns > and further defining the selection criteria - could the > layout being picked up have come from the source view or > does a column lock get stored somewhere other than in Sys_Layouts? > > Regards, > Alastair. > > > ---------------------------------- > A D B Burr, > St. Albans, UK. > ---------------------------------- > [EMAIL PROTECTED] > ---------------------------------- > > __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
