aurato

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 81 total)

RE: DBCC CheckTable returns following results, best way to deal with this?

GilaMonster (3/12/2013)
Drop the indexes 'IX_Advertise_BrandCopy_Price_Stock' and 'IX_ITEMS_ADVFLAG_PARETN_PRICE_STOCK' (on the table 'Items') and recreate them. Don't rebuild them, drop and recreate.
Doing so now. Our sysops guys checked the server and...

March 12, 2013 at 10:43 am

#1596144
RE: DBCC CheckTable returns following results, best way to deal with this?

GilaMonster (3/12/2013)
Please run the following and post the full, complete and unedited output.
DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS
Msg 8951, Level 16, State 1, Line 1
Table error: table 'Items' (ID...

March 12, 2013 at 9:50 am

#1596100
RE: DBCC CheckTable returns following results, best way to deal with this?

GilaMonster (3/12/2013)
Please run the following and post the full, complete and unedited output.
DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS
Running this now.
EDIT: This may take some time. It's only 5% done...

March 12, 2013 at 8:41 am

#1596055
RE: DBCC CheckTable returns following results, best way to deal with this?

Also, neither is the PK or a FK or clustered.

March 12, 2013 at 8:07 am

#1596032
RE: Accidentally added a new file to a production database

I ran this:
USE PRICETOOL --Name of database in question
GO
DBCC SHRINKFILE (DummyFile, EMPTYFILE)
GO
ALTER DATABASE PRICETOOL
REMOVE FILE DummyFile
GO
I received this as output:
DbIdFileIdCurrentSizeMinimumSizeUsedPagesEstimatedPages
74384 ...

May 1, 2012 at 2:07 pm

#1482093
RE: Accidentally added a new file to a production database

My method of testing this on a test server will be this:
1) Add file to primary filegroup of test version of the same database.
2) Add a new table with some...

May 1, 2012 at 1:55 pm

#1482090
RE: Accidentally added a new file to a production database

PaulB-TheOneAndOnly (5/1/2012)
aurato (5/1/2012)
PaulB-TheOneAndOnly (5/1/2012)
aurato (5/1/2012)
And it's on a low-performant drive. Is there any salvaging this or do I need to do a restore? I don't know how soon...

May 1, 2012 at 1:52 pm

#1482088
RE: Accidentally added a new file to a production database

PaulB-TheOneAndOnly (5/1/2012)
aurato (5/1/2012)
And it's on a low-performant drive. Is there any salvaging this or do I need to do a restore? I don't know how soon it's going...

May 1, 2012 at 12:56 pm

#1482034
RE: Moved 25GB table to new filegroup on a different drive, but no space gain in original data file?

Perry Whittle (4/11/2012)
can you post the table definition and the exact command you used to move the table?
I was about to, wondering what you might learn from it when I...

April 11, 2012 at 11:05 am

#1472058
RE: Are Check Constraints costly?

Gianluca Sartori (3/2/2012)
No, you won't even notice the difference.
CHECK constraints can get expensive when built with scalar UDFs with data access. Otherwise, the cost is negligible.
Thank you.

March 2, 2012 at 9:29 am

#1454268
RE: Trying to figure out why this is a full table scan

SQLKnowItAll (3/1/2012)
aurato (3/1/2012)
SQLKnowItAll (3/1/2012)
Umm... Unless I missed something, you are trying to change the data type on a production table that is accessed by Great Plains? I'm not so sure...

March 1, 2012 at 12:13 pm

#1453822
RE: Trying to figure out why this is a full table scan

SQLKnowItAll (3/1/2012)
Umm... Unless I missed something, you are trying to change the data type on a production table that is accessed by Great Plains? I'm not so sure it is...

March 1, 2012 at 11:09 am

#1453791
RE: Trying to figure out why this is a full table scan

GilaMonster (3/1/2012)
aurato (3/1/2012)
GilaMonster (3/1/2012)
aurato (3/1/2012)
GilaMonster (3/1/2012)
Chance the #StatusHistory temp table not the permanent table. You'll need to drop all indexes and constraints on that column first, change the data type...

March 1, 2012 at 8:07 am

#1453652
RE: Trying to figure out why this is a full table scan

GilaMonster (3/1/2012)
aurato (3/1/2012)
GilaMonster (3/1/2012)
Chance the #StatusHistory temp table not the permanent table. You'll need to drop all indexes and constraints on that column first, change the data type and then...

March 1, 2012 at 8:03 am

#1453647
RE: Trying to figure out why this is a full table scan

GilaMonster (3/1/2012)
Chance the #StatusHistory temp table not the permanent table. You'll need to drop all indexes and constraints on that column first, change the data type and then recreate the...

March 1, 2012 at 7:56 am

#1453639

Viewing 15 posts - 16 through 30 (of 81 total)