Jim >Until you raised this question I hadn't really considered >the question of how views are unloaded.
Nor had I and by reporting it I hoped to make anybody else who hadn't sit up and take notice. There must be quite a few newish readers on the list who can make use of info like this even though some of the more long-established ones know it already. Anyway, glad to have alerted you. As Ian (hi, Ian) also pointed out temp views solve the problem but if the view is an integral part of the application it _ought_ to be safe to keep it in the database. I think that the real point that needs to be addressed, however, is that if a user backs-up and _immediately_ restores - absolutely nothing else done but changing the name of the current database to allow the backup file to create the same database name - then I think most people would expect that to work perfectly and especially so with the system tables. It's all very well for those of us who don't mind playing in the sys_tables area and understand why a view or a table needs to be created before another but it shouldn't be a requirement in my view (no pun intended). Anybody else agree or am I expecting too much? Regards, Alastair. ----- Original Message ----- From: "James (Jim) Bentley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 23, 2002 3:10 PM Subject: Re: Two points to be aware of: Error on Layouts, BackUp & Restore > 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/ ================================================ 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/
