Sorry - sent reply to wrong address!
Steve Vellella Office: 409-944-3904 Cell: 520-250-6498 From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Monday, April 09, 2012 10:54 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: strange database errors Except in the case of a temporary view! Dennis McGrath Software Developer QMI Security Solutions 1661 Glenlake Ave Itasca IL 60143 630-980-8461 [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Kenny Camp Sent: Monday, April 09, 2012 10:37 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: strange database errors I never use an *, Razzak taught me that many versions ago :-) I agree, using an * would be asking for trouble . Kenny From: [email protected] [mailto:[email protected]] On Behalf Of Bill Downall Sent: Monday, April 09, 2012 10:08 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: strange database errors James, Any view defined as with an asterisk will be corrupted by a change to the number of columns or their data types in an underlying table: CREATE VIEW mySubsetView AS SELECT * from tablename WHERE whatever Bill On Mon, Apr 9, 2012 at 11:05 AM, Bill Eyring <[email protected]> wrote: James, Not Every view, only the ones giving a problem. Before making schema changes to an underlying table included in a view, I would unload the structure for the view, drop the view, make the schema change, edit the view structure then run the view structure file to re-instate the view. I believe there would be a problem in all versions if you don't do the above. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle Sent: Monday, April 09, 2012 9:35 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: strange database errors Bill, Are you saying EVERY view must be dropped if you make changes to a table such as adding a column? I remember from 6.5 days that was a problem but thought when I went to 7.6 you did not have to drop the view before any changes. James Belisle Making Information Systems People Friendly Since 1990 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bill Eyring Sent: Monday, April 09, 2012 7:56 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: strange database errors Dave, Kenny Usually I've seen these problems in views where schema changes to tables have been made without first dropping views based on the table changed. Another instance is in forms where an On Before Design eep that defines a view or temp table contains an error. One way you can check this is; Backup database to a different directory Out DBName.all Unload ALL Out screen Edit DBName.all and search for the offending table/view references that produced the errors. If nothing is found then try this; Trace DBNAme.all - when an error is produced note the line # then edit and fix. Also at the R> prompt do a List Pkeys then a List Fkeys, check the references and go to the table designer and delete the offending foreign key. Try a List Rules and see if you can find the offending rule and delete using the Table Designer. Hope some of this helps. Bill Eyring -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave McCann Sent: Friday, April 06, 2012 11:18 PM To: RBASE-L Mailing List Subject: [RBASE-L] - strange database errors I've been up against a wall with a recent database problem on one of my projects, hoping I can get some ideas. Recently my database began having this issue, whenever I go to add a column or make pretty much any structural change, I get an ERROR - A foreign key references a table not known to be referenced (1242), followed by an ERROR - The number of rows counted was not expected. I have been able to UNLOAD my structure and recreate the database with seemingly no errors, database checks out OK with AUTOCHK and R:Scope afterwards, but as soon as I go to edit the structure the errors return. Running R:Scope the errors are invalid row count errors in SYS_RULES, SYS_CONSTRAINTS, and SYS_COMMENTS. I suspected something wrong with a constraint or rule because I've made adjustments in those areas in the last month and since the initial error indicates a problem with a foreign key. Any ideas about how I could go about narrowing down the specific problem? Since everything was valid when setup, and again when structure was recreated just not quite sure why/how this could be happening. -- Dave McCann
