> then I think most people > would expect that to work perfectly and especially so with the system > tables. Just to clarify my intentions - in case anyone thought I meant restore under any circumstances - I don't: corrupt data files or user created errors (such as my rule problem the other day) are nothing to do with the R:Base _system_ and should, obviously I hope, produce an error. All I was hoping to do was to expose a potential problem for new(ish) users who might not be aware of the pitfalls of views based on views because, as far as I am aware, there is no reference to this sort of thing in the documentation.
Regards, Alastair. ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 23, 2002 8:58 PM Subject: Re: Two points to be aware of: Error on Layouts, BackUp & Restore > 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/ ================================================ 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/
