Alastair, fwiw, I decided long ago (2.11) that simply zipping data files to backup disks/locations/tape was easiest and least susceptible to the vagaries of my own memory and customer circumstance. I also develop views within files with "create view" and maintain their definition and order of dependence there.
Ben Petersen On 22 Feb 2002, at 19:04, Alastair Burr 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] > ---------------------------------- > > ================================================ 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/
