Boring
asked on
Error 624
We have just upgraded our database server to a 14 processor ultrasparc and are now having a problem with one of the tables in the database.
We dumped the database and reloaded it on the new machine and now one of the tables is giving us error 625 (Could not retrieve row from logical page %ld via RID because the entry in the offset
table for that RID is less than or equal to 0.) whenever we try to update it from a trigger in another table in the database. DBCC shows no errors and we have even dropped the table and BCP'd the data back into it but still the error occurs.
We are also getting the occasional error 693, 625, and 605 but again only on this table even after we have recreated it.
Has anyone any ideas of what this can be and how to fix it?
Thanks
We dumped the database and reloaded it on the new machine and now one of the tables is giving us error 625 (Could not retrieve row from logical page %ld via RID because the entry in the offset
table for that RID is less than or equal to 0.) whenever we try to update it from a trigger in another table in the database. DBCC shows no errors and we have even dropped the table and BCP'd the data back into it but still the error occurs.
We are also getting the occasional error 693, 625, and 605 but again only on this table even after we have recreated it.
Has anyone any ideas of what this can be and how to fix it?
Thanks
Have you tried this:
find which index may be used by the trigger.
drop the index and recreate it.
or
(re)create a clustered index on the table
The above solutions come from the Sybase error messages book.
Also maybe the problem is at the table the trigger fires from, maybe recreate the trigger? Or the entire table?
Good luck...
Arjan
find which index may be used by the trigger.
drop the index and recreate it.
or
(re)create a clustered index on the table
The above solutions come from the Sybase error messages book.
Also maybe the problem is at the table the trigger fires from, maybe recreate the trigger? Or the entire table?
Good luck...
Arjan
I think I have run into this before. Try to recreate the trigger and all stored procedures it calls.
If that won't help, send here output of the 'select @@version' command (the version string).
If that won't help, send here output of the 'select @@version' command (the version string).
ASKER
I have found the section of the trigger causing the problem. This worked before we moved onto the new machine. The Trigger is stored in the OrderLine table and is triggered on a Status update and acts on ChargeLine.
Comment this section out and all work fine. This should never have hit we can find no line where this delete would delete anything. Any thoughts?
/* delete ChargeLine where Charged <> 'y'
AND (BatchNo=0 or BatchNo is NULL)
AND exists(select * from inserted i
where i.OrderNo=ChargeLine.Order No
AND i.SectionID=ChargeLine.Sec tionID
AND i.LineRef=ChargeLine.LineR ef
AND ((i.LineStatus<>"3" AND i.LineStatus<>"3a" AND i.LineStatus<>"8") OR i.LineStatus is NULL))
AND exists(select * from deleted d
where d.OrderNo=ChargeLine.Order No
AND d.SectionID=ChargeLine.Sec tionID
AND d.LineRef=ChargeLine.LineR ef
AND (d.LineStatus="3" OR d.LineStatus="3a" OR d.LineStatus="8"))
Comment this section out and all work fine. This should never have hit we can find no line where this delete would delete anything. Any thoughts?
/* delete ChargeLine where Charged <> 'y'
AND (BatchNo=0 or BatchNo is NULL)
AND exists(select * from inserted i
where i.OrderNo=ChargeLine.Order
AND i.SectionID=ChargeLine.Sec
AND i.LineRef=ChargeLine.LineR
AND ((i.LineStatus<>"3" AND i.LineStatus<>"3a" AND i.LineStatus<>"8") OR i.LineStatus is NULL))
AND exists(select * from deleted d
where d.OrderNo=ChargeLine.Order
AND d.SectionID=ChargeLine.Sec
AND d.LineRef=ChargeLine.LineR
AND (d.LineStatus="3" OR d.LineStatus="3a" OR d.LineStatus="8"))
ASKER
We have recreated everything on the table we currently have one clustered and one non clustered index. And like I said we have compleatly destroyed and re-created the whole table.
ASKER
Adaptive Server Enterprise/11.9.2/1031/P/S un_svr4/OS 5.5.1/FBO/Fri Aug 14 06:26:45 1998
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It could be the problem with the Hardware too.
so U ,where and hoe Ur datafile R ,if it is in file system and in Raid too ,
then U have to understood how Ur operating system is taking care of UR ASE while writing to disk. Secondly ,Do check on which device Ur table is located and try to change is to some other physical device .
R U facing this problem
1.with certain table or all the table on that device .
2. that table size and number of transaction on that table compare to other table on the same device.
3. and hoe frequent U R doing Transaction on that table ,
4. Does that table contain the varchar datatype and null field on col.
5.Does Index contain the varchar field.and hoe frequently U r modifying it.
Those going to be the decieding factor for the wheather problem is with device or ASE problem.
so U ,where and hoe Ur datafile R ,if it is in file system and in Raid too ,
then U have to understood how Ur operating system is taking care of UR ASE while writing to disk. Secondly ,Do check on which device Ur table is located and try to change is to some other physical device .
R U facing this problem
1.with certain table or all the table on that device .
2. that table size and number of transaction on that table compare to other table on the same device.
3. and hoe frequent U R doing Transaction on that table ,
4. Does that table contain the varchar datatype and null field on col.
5.Does Index contain the varchar field.and hoe frequently U r modifying it.
Those going to be the decieding factor for the wheather problem is with device or ASE problem.
ASKER
I am SOOO sorry that I did not accept your answer quickly. Is there any way I can up the autograde to a better one?
ASKER