The dependent views problem is not unique to R:Base. SQL server goes R:Base one better and unloads views in alphabetical order!
Our solution is to have a file that creates all the views needed in a database, in the required order. Note that in R:Base databases, modifying a view will move it to the end of the table, so if it has any dependent views, modify them also, or better yet, use a command file as above, and modify the definition in the command file. "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] >---------------------------------- > > -- __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.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/
