Interestingly, all you have to do is reload the data in SYS_PROCEDURES to cover that base. Our "rebuild" process does nothing specific with regards to stored procedures other than let the data load.
Emmitt Dove Manager, DairyPak Business Systems Evergreen Packaging, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] (203) 643-8022 -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of James Bentley Sent: Thursday, July 24, 2008 3:51 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Reports with no pages. Emmitt, Don't forget that now a days you also need to take care of STORED PROCEDURES if used. Jim Bentley American Celiac Society [EMAIL PROTECTED] tel: 1-504-737-3293 --- On Thu, 7/24/08, Emmitt Dove <[EMAIL PROTECTED]> wrote: > From: Emmitt Dove <[EMAIL PROTECTED]> > Subject: [RBASE-L] - RE: Reports with no pages. > To: "RBASE-L Mailing List" <[email protected]> > Date: Thursday, July 24, 2008, 6:55 AM > Tom, > > > > Back in the mid-90s I would periodically have gremlins in > the database that > couldn't be purged using even UNLOAD / RUN, so I > developed a technique that > *always* works. > > > > 1) Create (and maintain) a structure file with only > the CREATE TABLE > commands > > 2) Create a command file to recreate KEYS > > 3) Create a command file to recreate INDEXES > > 4) Create a command file to recreate COMMENTS > > 5) Create a command file to recreate AUTONUMBERS > > 6) Create a command file to recreate VIEWS > > 7) Create a command file to recreate SATTACHes > > > > If your database includes RULES, you'll need a command > file for those also. > > > > Now, to completely rebuild the database: > > > > 1) CONNECT to your database, output to a file and > UNLOAD DATA > > 2) Rename the old database > > 3) RUN the structure file > > 4) RUN the data unload > > 5) RUN the keys file > > 6) RUN the indexes file > > 7) RUN the comments file > > 8) RUN the autonumbers file > > 9) RUN the views file > > 10) RUN the sattach file > > > > When the process is complete, you will have a brand new > database with all > the old data, free of any gremlins. > > > > Note that to make the process simpler to maintain, our > databases have tables > in them to contain the data elements necessary for creating > indexes, > comments and autonumbers, and the command files simply run > a cursor against > the table, building the CREATE INDEX, COMMENT ON or AUTONUM > command from the > data. The data of course gets reloaded earlier, so it is > present when > required. > > > > This may seem like using a sledge hammer to drive a carpet > tack, but believe > me, it has proven invaluable on many occasions. If you can > get the data > from an old database, you can build a brand-spanking new > one with ease. > > > > Emmitt Dove > > Manager, DairyPak Business Systems > > Evergreen Packaging, Inc. > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > (203) 643-8022 > > > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Tom > Frederick > Sent: Wednesday, July 23, 2008 5:51 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: Reports with no pages. > > > > Dawn, > > So I am on a teleconference phone call and decide to try > RELOAD one more > time, figuring what could it hurt. (Shows how exciting the > teleconference > was.) Do the RELOAD, open the new database, and ..all the > reports and views > work again. Only did 3-4 previous RELOADS with no change. > Why now? There has > to be something floating through my database. But it sure > does not pop up in > any checks I have done so far. Move the reloaded database > to the compiler > drive. Everything works just as it did before all this > started. R:Scope may > be in my future. > > > > Tom Frederick > > Elm City Center > > 1314 W Walnut > > Jacksonville, IL 62650 > > Off - 217-245-9504 > > Fax - 217-245-2350 > > Email - [EMAIL PROTECTED] > > Web - www.elmcity.org > > _____ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Dawn Hast > Sent: Wednesday, July 23, 2008 3:47 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: Reports with no pages. > > > > Tom, > > > > If you can't browse the multi-table view, then the > problem isn't with your > report, but with the view itself. If your view definition > hasn't changed, > it's possible there's some kind of data / index / > other corruption. > > > > Dawn > > -------------- Original message from "Tom > Frederick" > <[EMAIL PROTECTED]>: -------------- > > > > Larry, > > I can browse the single table view because data shows > up. If there is a > > second table, the view is empty. Have not tried the > temp table approach. > > The report fails every time the report uses a multi > table view. It works > > perfect every time for single. I have gone back to > reports I have not > > run in months that use totally different > data/views/tables and have > > always worked. They now fail if they are multi table. > > > > All views and reports are built using the Database > Explorer menu choices > > like I always have. This only started in the last week > or so. Have done > > RELOADS and other suggestions from this group when > stuff does not work > > right. Even reloaded V8 because a weird table > "484ee4ee" showed up that > > was a duplicate of another table, but I never built it > and this was on a > > home machine that no one else messes with. It went > away only after I > > erased all rows except the PK row. A puzzler. > > > > Tom Frederick > > Elm City Center > > 1314 W Walnut > > Jacksonville, IL 62650 > > Off - 217-245-9504 > > Fax - 217-245-2350 > > Email - [EMAIL PROTECTED] > > Web - www.elmcity.org > > > > -----Original Message----- > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Lawrence > > Lustig > > Sent: Wednesday, July 23, 2008 11:36 AM > > To: RBASE-L Mailing List > > Subject: [RBASE-L] - RE: Reports with no pages. > > > > << > > I am seeing the same thing. > > >> > > > > Glad to know I'm not going nuts. Well, on this > particular matter, > > anyway. > > > > A few questions: > > > > Are the problems you're seeing ONLY in printing > reports? Can you browse > > the data in the view? In my experimenting yesterday I > found that if I > > tried to count records from the view with a SELECT > COUNT before > > printing, I would get back records -- eg, I could > "see" them in the > > view. It was only when I went to print the report that > I got nothing > > back. > > > > The reports that don't work for you -- do they > fail every single time, > > or only sometimes? Mine "start out" okay, > but after "some amount" of > > time some of the reports stop working. I'm > assuming that I'm doing > > something environmental (too many variables, some > setting) that's > > causing it not to work. > > > > You say you've traced the problem to reports based > on multi-table views? > > If you PROJECT the data into a temp table and then > print, does that > > solve the problem? It would be a work around for me in > some cases. > > -- > > Larry > > > >
