SQL PROBLEM ON F0911

Has anybody come across this error message before. or have any idea what
could cause it.
This is a 'Sql Server 7 SP3' Error Message. We are getting errors whenever
we try to read thru the file.

Server: Msg 8909, Level 16, State 1, Line 1
Table Corrupt: Object ID 1069962888, index ID 0, page ID (1:3231222). The
PageId in the page header = (1:3078682).
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1069962888, index ID 0: Page (1:3231222) could not be processed.
See other errors for details.
Server: Msg 8909, Level 16, State 1, Line 1
Table Corrupt: Object ID 1069962888, index ID 0, page ID (1:3231223). The
PageId in the page header = (1:3074575).
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 1069962888, index ID 0: Page (1:3231223) could not be processed.
See other errors for details.
DBCC results for 'PRODDTA.F0911'.
There are 3500031 rows in 350003 pages for object 'PRODDTA.F0911'.
CHECKTABLE found 0 allocation errors and 4 consistency errors in table
'PRODDTA.F0911' (object ID 1069962888).
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKTABLE (JDE_PRODUCTION.PRODDTA.F0911 ).


-Brian

Oneworld 7332
Sql Server 7 SP3
Windows NT 4.0 SP6

Brian Wilkinson
Senior Technical Specialist
Quickie Manufacturing
Phone: 856-829-7900 x143
E-Mail: [email protected]



William “Brian” Wilkinson
Quickie Manufacturing
[email protected]
856-829-7900 x143

Your DB appears to be corrupt, which happens sometimes if the server
crashes.

A form of "dbcc checktable" or "dbcc checkdb" would usually fix it, but it
could in rare cases make it worse, so have a good backup before you start,
run it when there are no users and be prepared to wait for hours until if
finishes.

You may have to run it a few times until it stops giving you error
messages...

Regards,
Alexander Pastuhov

try to export this table to access database and then rename the orginal sql table, then import the access table to a sql table with the same name....maybe it could help

Brian,

I have had this happen with different tables. If you have a support
contract with Microsoft, I would definitely contact them. Even if you
don't, I would still contact them (it's about $250 per call opened .... well
worth it .... they've always been VERY helpful to me).

Running DBCC CHECKDB('db_name', 'REPAIR_ALLOW_DATA_LOSS') has worked for me.
I have had to run it a couple of times in row in order to repair all of the
errors. Unfortunately, there's no way to know if or what data loss you may
or may not have had. The potential data loss can be anything in the table
... from a new record to a record several years old to specific pieces of
data in a record. As far as I've been able to tell, we haven't experienced
any data loss. Do you have another instance of SQL installed? Ideally what
you want to do is restore your most recent backup to maybe another server or
as a different database and try out the repair there. So far the longest my
repairs have taken are about an hour.

Good luck!
Michelle Dulay
ERP Coordinator
Goodrich Pump & Engine Control Systems, Inc.
[email protected]

OneWorld Xe, SP 18.1, Update 2
ESU JD10371, JD10833, JD11176, JD12367
Windows 2000 Deployment / Enterprise
SQL 2000



Michelle Dulay
OneWorld Xe, SP 18.1, Update 2
Windows 2000 Deployment / Enterprise
SQL 2000

Brian :

You've got corrupted space allocation of your F0911 table.
You have to :

a) Save F0911 structure. Use Enterprise Manager to script that table
(fields, indexes, primary key, permissions) and save it as
f0911.sql; this file will contain the CREATE TABLE... CREATE INDEX...
ALTER TABLE ADD CONSTRAINT... GRANT... etc that will allow you to
regenerate the table correctly.
b) Save its data. You may other create a cloned F0911 (without
indexes) on some other database in the same server or on another
server with enough room to accomodate your 3500000 registers and
transfer records via DTS from damaged table to this temporary storage.
I personally prefer to recreate F0911 on some other SQL databases,
others prefer to export data via command line tool 'bcp'. It's up to
you to choose what suits you the best. Nevertheless, I recommend you
not to use Access, 3500000 records are too much for that tool!
c) Run DBCC CHECKDB ('JDE_PRODUCTION') WITH ALL_ERRORMSGS on your
server. Perhaps there are some other bugs lurking... Be aware that
this check may run for several hours.
d) Run DROP TABLE PRODDTA.F0911
e) Run your F0911.SQL script to recreate F0911 table with its
fields, primary key, indexes, permissions, etc. You can also recreate
F0911 with OneWorld, by checkout - generate table.
f) Import your data. If you saved that with DTS you should recover it
via DTS. If you saved it with bcp, then use it to restore these records.
g) Run DBCC CHECKTABLE ('PRODDTA.F0911') on your JDE_PRODUCTION

Regards, Sebastian Sajaroff
B7321 to Xe, NT, W2K, SQL, Citrix

Thanks for the suggestions.

Here is what I did to fix it this. I finished at 4 am this morning :>.

I noticed that the errors were all in the indexes.
So I Dropped all the indexes (yes I scripted them first).
I then tried to recreate them and got a duplicate error.
So I found the duplicate records and copied them to a hold table.
I then recreated the indexs with no problem.
Accounting is now dealing with the deleted records (was only 2 OV orders).

Oh and according to JDEdwards the only fix is to restore the table from
backup.

Nice to see the Jdelist was on the right track. Maybe we should starting
paying our maintenance fees to the list.

-Brian




William “Brian” Wilkinson
Quickie Manufacturing
[email protected]
856-829-7900 x143