Javier: Trying this backup technique, I find the following:
1. You need to use UNLOAD STRUCT FOR VIEWS, as R:Base won't accept ALL there. 2. My constraints are getting unloaded in the wrong order, with PRIMARY KEYs listed in the file after the FOREIGN KEYs that reference them (presumably because the PK table structure was modified after the FK table and the tables got out of order). I have to run the constraints file twice, ignoring the "No Compatible Primary Key" message on the first run and then all the "Only one PRIMARY KEY per table" messages the second time. 3. I find that I must perform separate UNLOAD DATA operations on the tables SYS_PROCEDURES, SYS_PROC_COLS, and SYS_PROC_MODS. Then, I must load these three files before I try to run my table structures. The reason is that I have some tables with computed columns that run stored procedures — if these procedures have not yet been created the CREATE TABLE commands that depend on them fail. 4. Running the views file, I get the error 2968 "Dynamic table limit exceeded. All users must disconnect to reset it." after some number of views have been created. I have to disconnect, reconnect, and re-run the file (sometimes more than once) to be able to create all my views. Have you had experience with any of these issues? -- Larry ________________________________ From: Javier Valencia <[email protected]> To: RBASE-L Mailing List <[email protected]> Sent: Wednesday, May 2, 2012 4:58 PM Subject: [RBASE-L] - RE: Constraint troubleshooting? Buddy, R:Base has provided us a better way of doing this: OUTPUT MyDB.STR UNLOAD ALL FOR TABLEDEF OUTPUT MyDB.VIE UNLOAD ALL FOR VIEWS OUTPUT MyDB.CST UNLOAD ALL FOR CONSTRAINTS OUTPUT MyDB.IND UNLOAD ALL FOR INDEXES OUTPUT MyDB.RUL UNLOAD ALL FOR RULES OUTPUT MyDB.ACC UNLOAD ALL FOR ACCESS OUTPUT MyDB.AUT UNLOAD ALL FOR AUTONUM OUTPUT MyDB.COM UNLOAD ALL FOR COMMENTS OUTPUT MyDB.TRG UNLOAD ALL FOR TRIGGERS OUTPUT MyDB.DAT UNLOAD DATA OUTPUT SCREEN And now you have all components separated and can load them as needed; using the TRACE feature lets you know exactly where the problem happens. Javier, Javier Valencia, PE O: 913-829-0888 H: 913-397-9605 C: 913-915-3137 From:[email protected] [mailto:[email protected]] On Behalf Of Walker, Buddy Sent: Wednesday, May 02, 2012 12:41 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Constraint troubleshooting? Karen What I have done in the past was this Make sure messages and error messages on are OUT whatever.ALL UNLOAD ALL OUT TERM In the whatever.all file I cut out all of the create views, create index and alter table I put each one of them in their own file. RENAME the old database Now using 9.1(64) Run whatever.all If this is really big database I would make a copy of it at this time. Run the create views file Run the create index file Since you are having problems with constraints I would Trace the alter table file. It should stop on the error. Buddy From:[email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, May 02, 2012 12:47 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Constraint troubleshooting? We used "unload all" to recreate the database for a recent upgrade from 7.6 to 9.1 64-bit. An autochk on the database gives us 6 instances of an error "A foreign key references a table not known to be referenced" on various tables. First I used some existing code I had to create a cursor thru all FK columns and write out what PK column/table it references per the sys_indexes table, and also displayed the "referenced" flag of that PK. Everything looks great. So then I did an "unload schema" and looked at the bottom at all the FKs (luckily only 25 of them) and all of them reference good tables & columns. If I list each PK table, each one shows "PK referenced". Anyone have a clue what that message means and how I can find out what the offending entries are? If we reload the database, the reloaded copy shows the same errors. Karen
