Help Files driving me crazy

I have broken HTML links all over in my help files. It
drives me nuts. The error I get is :
An error has occured on this page.
Object does not support this property.
What can I do to fix this ? I have Windows XP Professional.reinstall them.
"Jack A" <anonymous@.discussions.microsoft.com> wrote in message
news:f57801c3bdc1$1c798690$a601280a@.phx.gbl...
> I have broken HTML links all over in my help files. It
> drives me nuts. The error I get is :
> An error has occured on this page.
> Object does not support this property.
> What can I do to fix this ? I have Windows XP Professional.

Help : Table Corrupt

Can not truncate or drop a table.
DBCC CHECKTABLE on the table returns the following message:
"Table Corrupt: IAM page (1:25040) (object ID 38016033,
index ID 0) is out of the range of this database."
Our version is Microsoft SQL Server 7.00 - 7.00.623
Can this corrupt other tables?
Thanks.Here are the general recommendations for handling a suspect or corrupt
database:
0. Ensure you have a backup strategy that you can use to recover from
hardware failures (including corruption). I recommend performing both
database and log backup in most situations.
1. If you can run DBCC CHECKDB against the database: Search Books Online and
KB for the error numbers that CHECKDB gives you. There might be specific
info for that type of error.
2. Find out why this happened. Check eventlog, do HW diagnostics etc.;
search Books Online and KB for those errors. You don't want this to happen
again! If the database is suspect, the file might have been in use by for
instance an anti-virus program and restarting SQL Server might be all that
is needed - but you still want to read logs etc to find out what happened.
3. If there is a hardware problem, ensure the faulty hardware is replaced.
4. Backup the log. This assumes that log backup schedule is in place, of
course. If the database is suspect, then the NO_TRUNCATE option for the
RESTORE command must be used. Also, you might want to do a file backup of
the mdf and ldf files, for extra safety.
5. Restore is the best thing to do now. If you managed to backup log as per
step 4, then you will most probably have zero dataloss. You should restore
the latest clean database backup and the subsequent log backups including
the one taken in above step.
If the database isn't suspect, then DBCC with a REPAIR option might be a
secondary option but this will often result in loss of data. Additional
solutions, depending on the errors, may be to manually rebuild non-clustered
indexes, manually drop and reload a table if the data is static, and so on.
If the database is suspect, a secondary option can be to try to "un-suspect"
the database using sp_resetstatus. Read about it (books online, KB, google
etc). It might help but if the database is too damaged, it might just pop
back to suspect again. There's also something called "emergency mode" which
is a "panic" status you can set in order to try to get data out of a damaged
database. I think the name of that option speaks for itself. Again search
the net for info.
If you feel uncertain with above steps, I recommend letting MS hand-hold you
through the steps appropriate for your particular situation.
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=...ublic.sqlserver
"xeiger" <xeiger@.yahoo.es> wrote in message
news:baf601c3ecce$8df61a40$a001280a@.phx.gbl...
> Can not truncate or drop a table.
> DBCC CHECKTABLE on the table returns the following message:
> "Table Corrupt: IAM page (1:25040) (object ID 38016033,
> index ID 0) is out of the range of this database."
> Our version is Microsoft SQL Server 7.00 - 7.00.623
> Can this corrupt other tables?
> Thanks.

Help : Table Corrupt

Can not truncate or drop a table.
DBCC CHECKTABLE on the table returns the following message:
"Table Corrupt: IAM page (1:25040) (object ID 38016033,
index ID 0) is out of the range of this database."
Our version is Microsoft SQL Server 7.00 - 7.00.623
Can this corrupt other tables?
Thanks.Here are the general recommendations for handling a suspect or corrupt
database:
0. Ensure you have a backup strategy that you can use to recover from
hardware failures (including corruption). I recommend performing both
database and log backup in most situations.
1. If you can run DBCC CHECKDB against the database: Search Books Online and
KB for the error numbers that CHECKDB gives you. There might be specific
info for that type of error.
2. Find out why this happened. Check eventlog, do HW diagnostics etc.;
search Books Online and KB for those errors. You don't want this to happen
again! If the database is suspect, the file might have been in use by for
instance an anti-virus program and restarting SQL Server might be all that
is needed - but you still want to read logs etc to find out what happened.
3. If there is a hardware problem, ensure the faulty hardware is replaced.
4. Backup the log. This assumes that log backup schedule is in place, of
course. If the database is suspect, then the NO_TRUNCATE option for the
RESTORE command must be used. Also, you might want to do a file backup of
the mdf and ldf files, for extra safety.
5. Restore is the best thing to do now. If you managed to backup log as per
step 4, then you will most probably have zero dataloss. You should restore
the latest clean database backup and the subsequent log backups including
the one taken in above step.
If the database isn't suspect, then DBCC with a REPAIR option might be a
secondary option but this will often result in loss of data. Additional
solutions, depending on the errors, may be to manually rebuild non-clustered
indexes, manually drop and reload a table if the data is static, and so on.
If the database is suspect, a secondary option can be to try to "un-suspect"
the database using sp_resetstatus. Read about it (books online, KB, google
etc). It might help but if the database is too damaged, it might just pop
back to suspect again. There's also something called "emergency mode" which
is a "panic" status you can set in order to try to get data out of a damaged
database. I think the name of that option speaks for itself. Again search
the net for info.
If you feel uncertain with above steps, I recommend letting MS hand-hold you
through the steps appropriate for your particular situation.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"xeiger" <xeiger@.yahoo.es> wrote in message
news:baf601c3ecce$8df61a40$a001280a@.phx.gbl...
> Can not truncate or drop a table.
> DBCC CHECKTABLE on the table returns the following message:
> "Table Corrupt: IAM page (1:25040) (object ID 38016033,
> index ID 0) is out of the range of this database."
> Our version is Microsoft SQL Server 7.00 - 7.00.623
> Can this corrupt other tables?
> Thanks.

Help - "Could not allocate space for object as the secondary group is full" error

Hello Peers,
We have a database in SqlServer 2K with a following settings:
Primary Group Size: 1024MB
Secondary Group Size: 1023 MB
Transaction Log size: 236 MB
File Growth: 10%
Recover Model: Simple
Auto Shrink: OFF
Recovery Model: Simple
We have a table "TestTable' that has 400,000 records. All the indexes
for the table is on the Secondary group.
The problem is, when we alter a size of the column and save the
changes in EnterPriseManager, we get the error "Could not allocate
space for object 'TestTable' in database 'TestDb' because the
'Secondary' filegroup is full." We get the same error when we use
"Alter Column" command in Query Analyzer as well(We have run "Dbcc
ShrinkFile" before running the alter table command).
Could anyone throw some light on altering the size of columns on a
table with 400000+records without any problems like the one above?
TIA for any help.
Regards
Pradeep.L
On May 11, 11:56 am, pradee...@.hotmail.com wrote:
> Hello Peers,
> We have a database in SqlServer 2K with a following settings:
> Primary Group Size: 1024MB
> Secondary Group Size: 1023 MB
> Transaction Log size: 236 MB
> File Growth: 10%
> Recover Model: Simple
> Auto Shrink: OFF
> Recovery Model: Simple
> We have a table "TestTable' that has 400,000 records. All the indexes
> for the table is on the Secondary group.
> The problem is, when we alter a size of the column and save the
> changes in EnterPriseManager, we get the error "Could not allocate
> space for object 'TestTable' in database 'TestDb' because the
> 'Secondary' filegroup is full." We get the same error when we use
> "Alter Column" command in Query Analyzer as well(We have run "Dbcc
> ShrinkFile" before running the alter table command).
> Could anyone throw some light on altering the size of columns on a
> table with 400000+records without any problems like the one above?
> TIA for any help.
> Regards
> Pradeep.L
Pradeep.L,
If you right click on your database in EM and select "Properties" and
"Data File tab" what do you see? Is the "restrict file growth" radio
button checked? Are you trying to make the db bigger than is allowed?
Or are you running out of disc space on the drive where this db/file
group is stored?
Kristina
|||Hello Kristina,
[vbcol=seagreen]
No. It is set to "Unrestricted File Growth" for Datafile and
Transaction log.
[vbcol=seagreen]
I'm not sure about this. The maximum db size that is permitted in our
machine is 2GB and it complains that the cumulative size should not
exceed 2048 MB due to the license policy.
[vbcol=seagreen]
group is stored?
There is 15GB free space in the partition in which sql server is
installed -
BTW, The purpose of trying out this issue is we need to increase the
size of quite a few columns in our production server.
Most of the columns are part of composite primary key/Index. We would
like to ensure that we don't land in sticky waters
when we go out with the change in our production server -
|||<pradeepln@.hotmail.com> wrote in message
news:1178942162.311166.101130@.e65g2000hsc.googlegr oups.com...
> Hello Kristina,
> No. It is set to "Unrestricted File Growth" for Datafile and
> Transaction log.
> I'm not sure about this. The maximum db size that is permitted in our
> machine is 2GB and it complains that the cumulative size should not
> exceed 2048 MB due to the license policy.
Ummm, 2048 MB IS 2GB.
Sounds like you've reached your max. Or I'm misunderstanding you.

> group is stored?
> There is 15GB free space in the partition in which sql server is
> installed -
> BTW, The purpose of trying out this issue is we need to increase the
> size of quite a few columns in our production server.
> Most of the columns are part of composite primary key/Index. We would
> like to ensure that we don't land in sticky waters
> when we go out with the change in our production server -
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html