jb@aablue.aablue.com (John B Scalia) (04/05/91)
(Posting this for a colleague, either post here or e-mail to clint@aablue.com, thanks!): I ran into a problem two days ago. First, I executed an SQL statement to get the count of the total records in a specific table and then I ran another one to get the count of those with valid reference field which is 6 records short of the total count. So I dumped all the records from this table and ran a delete statement in SQL mode to clean up the table. After I did that, I still got a record count of 6 in this supposedly empty table. I've concluded that I probably need to run SCOM on it, but I'd prefer a simpler way to get rid of these 6 bad records without spending another two and a half hours :). Any help will be appreciated. Clint. -------------- -- Respond to: | jb@aablue.com or | "Here's my .sig ain't it weird" uunet!aablue!jb |
itkin@mrspoc.Transact.COM (Steven M. List) (04/06/91)
clint@aablue.aablue.com writes: >I ran into a problem two days ago. First, I executed an SQL statement to get >the count of the total records in a specific table and then I ran another one >to get the count of those with valid reference field which is 6 records short >of the total count. So I dumped all the records from this table and ran a >delete statement in SQL mode to clean up the table. After I did that, >I still got a record count of 6 in this supposedly empty table. I've concluded >that I probably need to run SCOM on it, but I'd prefer a simpler way to >get rid of these 6 bad records without spending another two and a half >hours :). >Any help will be appreciated. > >Clint. Sounds to me like the datablock is corrupted. There are a couple of things to be tried. 1. find out what values are stored in the reference field in those mysterious records, replace them with VALID values, then try deleting them. 2. run REPOINT on the parent and child tables and check the error log. See if you can delete them then. 3. combine 1 and 2 If none of this works, or if it looks like it's going to take longer than 2 1/2 hours, then your only option will be to dump and reload. It's not clear that SCOM will do the job, since it dumps good AND bad records. You might also consider checking indexes and hash table. They can cause problems. Finally, you might consider calling Unify Tech Support and asking for "dbck", an unreleased database sanity checker that does many of these tasks as part of a larger process (like fsck). -- +----------------------------------------------------------------------------+ : Steven List @ Transact Software, Inc. :^>~ : : Chairman, Unify User Group of Northern California : : itkin@Transact.COM :
dougw@fdls.odag.or.gov (Doug Walker) (04/07/91)
In <1991Apr5.004919.9136@aablue.com> jb@aablue.aablue.com (John B Scalia) writes: >I ran into a problem two days ago. First, I executed an SQL statement to get >the count of the total records in a specific table and then I ran another one >to get the count of those with valid reference field which is 6 records short >of the total count. So I dumped all the records from this table and ran a >delete statement in SQL mode to clean up the table. After I did that, >I still got a record count of 6 in this supposedly empty table. I've concluded >that I probably need to run SCOM on it, but I'd prefer a simpler way to >get rid of these 6 bad records without spending another two and a half >hours :). >Any help will be appreciated. I am assuming you are using Unify 4.x; not their newer product Unify 2000 which I have not used. Their SCOM utility reconfigures the data base and is used primarily when adding tables, fields, or increasing the number of expected records. I don't SCOM will solve your above problem. I believe you need to use their REPOINT utility which will rebuild the expicity relationships within the database. For those records where it cannot do this (which is probably your case here), it will write information to file repoint.err which you can use to correct the problem. The Database Reference Manual documents what REPOINT does and explains in detail how to use it. Be sure to read the manual section where you can rebuild selected explicit relationships as this will cut down dramatically on your run time. Hope this helps. -- ----------------------------------------------------------------------------- Doug Walker uunet!fdls!dougw -or- dougw@fdls.odag.or.gov Oregon Department of Agriculture, Salem, Oregon (503) 378-3790
cookdl@stat.appstate.edu (04/17/91)
In article <1991Apr5.004919.9136@aablue.com>, jb@aablue.aablue.com (John B Scalia) writes: > (Posting this for a colleague, either post here or e-mail > to clint@aablue.com, thanks!): > > I ran into a problem two days ago. First, I executed an SQL statement to get > the count of the total records in a specific table and then I ran another one > to get the count of those with valid reference field which is 6 records short > of the total count. So I dumped all the records from this table and ran a > delete statement in SQL mode to clean up the table. After I did that, > I still got a record count of 6 in this supposedly empty table. I've concluded > that I probably need to run SCOM on it, but I'd prefer a simpler way to > get rid of these 6 bad records without spending another two and a half > hours :). > Any help will be appreciated. > > Clint. > -------------- > -- > Respond to: | > jb@aablue.com or | "Here's my .sig ain't it weird" > uunet!aablue!jb | I ran into the same thing a couple of years back. I cant find my notes on how i fixed it but you seem to have the right idea. Its a pain to fix but you may as well go for it. Unify's hotline is familiar with this i'm sure because they helped me fix this problem.