Hi,
I have a table setup running full-text index in sql server 2000. After
finishing 12 hrs long of initial full population, I immediately turned on the
"change tracking, update index in background". The full text index population
restart all over again even though there is no data change after that initial
full population. Could someone shed some light on this?
thanks,
-Leon
This is a known problem. I reported it to Microsoft I believe 3 years ago.
"Leon Lee" <Leon Lee@.discussions.microsoft.com> wrote in message
news:8425F683-75BB-44B6-9918-25E6781ABF32@.microsoft.com...
> Hi,
> I have a table setup running full-text index in sql server 2000. After
> finishing 12 hrs long of initial full population, I immediately turned on
> the
> "change tracking, update index in background". The full text index
> population
> restart all over again even though there is no data change after that
> initial
> full population. Could someone shed some light on this?
> thanks,
> -Leon
Showing posts with label index. Show all posts
Showing posts with label index. Show all posts
Sunday, February 19, 2012
Monday, February 13, 2012
After INDEX
Hi all,
I applaied a INDEX on a database with big table (8.000.000 recors) , my question is: If I act a Backup and after Restore this backup I will obtain a increase of performance, in other words on Restore of database is included a re-organization of INDEX.
sorry for my question but I need to know before try.
Thanks a lot
Hid
Yes, restored database will include re-orgnization of the index.
When you take the backup it includes everything at that point and restore will not change anything...
Sunday, February 12, 2012
Affect of FillFactor on Index
I am trying to understand how the fillfactor might be affecting the clusered
index.
The primary key (nonclustered) on the table is a composite index of two (int
data type) fields, where one field is an identity seed incrementing by one,
and the other field being more constant.
The non-unique clustered index (that seems to fragment quite often) is a
composite index of four columns:
lname varchar(35)
fname varchar(35)
mname varchar(35)
rptype char(12)
This index has a fillfactor of zero.
The row size on the table is about 900 bytes.
The number of reads versus writes is about 50:1 under normal activity, but
sometimes (once every two weeks or so) this table is loaded with
approximately 200-500 new records at one time.
With a row size of 900 bytes, I am getting about 8 rows a page.
I am trying to wrap by brain around what affect updates and inserts have.
Please help explain.
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1cbrichards via SQLMonster.com wrote:
> I am trying to understand how the fillfactor might be affecting the clusered
> index.
> The primary key (nonclustered) on the table is a composite index of two (int
> data type) fields, where one field is an identity seed incrementing by one,
> and the other field being more constant.
> The non-unique clustered index (that seems to fragment quite often) is a
> composite index of four columns:
> lname varchar(35)
> fname varchar(35)
> mname varchar(35)
> rptype char(12)
> This index has a fillfactor of zero.
> The row size on the table is about 900 bytes.
> The number of reads versus writes is about 50:1 under normal activity, but
> sometimes (once every two weeks or so) this table is loaded with
> approximately 200-500 new records at one time.
> With a row size of 900 bytes, I am getting about 8 rows a page.
> I am trying to wrap by brain around what affect updates and inserts have.
> Please help explain.
>
With a fill rate of 100%, clustered on lname (assuming this is "last
name"), you're going to see page splits (i.e. fragmentation) any time
you insert a new last name between two existing ones. Example:
LNAME: Jenkins
LNAME: Jones
These are stored on a data page, that page is 100% full. You insert a
new record:
LNAME: Johnson
Due to the clustered index, this new record belongs between the two
existing ones. However, since the data page containing those records is
full, it has to be split to make room for the new record.
Does that help?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Thanks Tracy...that makes sense.
When it comes to updates, at 900 bytes per row (and let's say 8 rows per page)
, that would leave approximately 800 bytes free per page (before any page
splits factor in) for updates, correct?
Tracy McKibben wrote:
>> I am trying to understand how the fillfactor might be affecting the clusered
>> index.
>[quoted text clipped - 20 lines]
>> I am trying to wrap by brain around what affect updates and inserts have.
>> Please help explain.
>With a fill rate of 100%, clustered on lname (assuming this is "last
>name"), you're going to see page splits (i.e. fragmentation) any time
>you insert a new last name between two existing ones. Example:
>LNAME: Jenkins
>LNAME: Jones
>These are stored on a data page, that page is 100% full. You insert a
>new record:
>LNAME: Johnson
>Due to the clustered index, this new record belongs between the two
>existing ones. However, since the data page containing those records is
>full, it has to be split to make room for the new record.
>Does that help?
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||cbrichards via SQLMonster.com wrote:
> Thanks Tracy...that makes sense.
> When it comes to updates, at 900 bytes per row (and let's say 8 rows per page)
> , that would leave approximately 800 bytes free per page (before any page
> splits factor in) for updates, correct?
Sounds right, I think...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||So, if I have 800 bytes free per page (based upon 900 and some bytes per row),
reducing the fillfactor to say, 80%, would not be that beneficial in reducing
page splits due to updates, correct?
Tracy McKibben wrote:
>> Thanks Tracy...that makes sense.
>> When it comes to updates, at 900 bytes per row (and let's say 8 rows per page)
>> , that would leave approximately 800 bytes free per page (before any page
>> splits factor in) for updates, correct?
>Sounds right, I think...
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||cbrichards via SQLMonster.com wrote:
> So, if I have 800 bytes free per page (based upon 900 and some bytes per row),
> reducing the fillfactor to say, 80%, would not be that beneficial in reducing
> page splits due to updates, correct?
>
Probably not. You'll reduce the frequency of the page splits, but you
will still eventually encounter them. Your options are to monitor
fragmentation, reindexing when necessary, or consider clustering on
different keys that aren't so prone to splitting.
I have a script that you might find useful for handling the
fragmentation. I'm currently rebuilding my web site, and don't have the
script online, but you can pull it from Google's cache by searching for
"www.realsqlguy.com/twiki/bin/view/RealSQLGuy/DefragIndexesAsNeeded".
Tracy McKibben
MCDBA
http://www.realsqlguy.com
index.
The primary key (nonclustered) on the table is a composite index of two (int
data type) fields, where one field is an identity seed incrementing by one,
and the other field being more constant.
The non-unique clustered index (that seems to fragment quite often) is a
composite index of four columns:
lname varchar(35)
fname varchar(35)
mname varchar(35)
rptype char(12)
This index has a fillfactor of zero.
The row size on the table is about 900 bytes.
The number of reads versus writes is about 50:1 under normal activity, but
sometimes (once every two weeks or so) this table is loaded with
approximately 200-500 new records at one time.
With a row size of 900 bytes, I am getting about 8 rows a page.
I am trying to wrap by brain around what affect updates and inserts have.
Please help explain.
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1cbrichards via SQLMonster.com wrote:
> I am trying to understand how the fillfactor might be affecting the clusered
> index.
> The primary key (nonclustered) on the table is a composite index of two (int
> data type) fields, where one field is an identity seed incrementing by one,
> and the other field being more constant.
> The non-unique clustered index (that seems to fragment quite often) is a
> composite index of four columns:
> lname varchar(35)
> fname varchar(35)
> mname varchar(35)
> rptype char(12)
> This index has a fillfactor of zero.
> The row size on the table is about 900 bytes.
> The number of reads versus writes is about 50:1 under normal activity, but
> sometimes (once every two weeks or so) this table is loaded with
> approximately 200-500 new records at one time.
> With a row size of 900 bytes, I am getting about 8 rows a page.
> I am trying to wrap by brain around what affect updates and inserts have.
> Please help explain.
>
With a fill rate of 100%, clustered on lname (assuming this is "last
name"), you're going to see page splits (i.e. fragmentation) any time
you insert a new last name between two existing ones. Example:
LNAME: Jenkins
LNAME: Jones
These are stored on a data page, that page is 100% full. You insert a
new record:
LNAME: Johnson
Due to the clustered index, this new record belongs between the two
existing ones. However, since the data page containing those records is
full, it has to be split to make room for the new record.
Does that help?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Thanks Tracy...that makes sense.
When it comes to updates, at 900 bytes per row (and let's say 8 rows per page)
, that would leave approximately 800 bytes free per page (before any page
splits factor in) for updates, correct?
Tracy McKibben wrote:
>> I am trying to understand how the fillfactor might be affecting the clusered
>> index.
>[quoted text clipped - 20 lines]
>> I am trying to wrap by brain around what affect updates and inserts have.
>> Please help explain.
>With a fill rate of 100%, clustered on lname (assuming this is "last
>name"), you're going to see page splits (i.e. fragmentation) any time
>you insert a new last name between two existing ones. Example:
>LNAME: Jenkins
>LNAME: Jones
>These are stored on a data page, that page is 100% full. You insert a
>new record:
>LNAME: Johnson
>Due to the clustered index, this new record belongs between the two
>existing ones. However, since the data page containing those records is
>full, it has to be split to make room for the new record.
>Does that help?
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||cbrichards via SQLMonster.com wrote:
> Thanks Tracy...that makes sense.
> When it comes to updates, at 900 bytes per row (and let's say 8 rows per page)
> , that would leave approximately 800 bytes free per page (before any page
> splits factor in) for updates, correct?
Sounds right, I think...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||So, if I have 800 bytes free per page (based upon 900 and some bytes per row),
reducing the fillfactor to say, 80%, would not be that beneficial in reducing
page splits due to updates, correct?
Tracy McKibben wrote:
>> Thanks Tracy...that makes sense.
>> When it comes to updates, at 900 bytes per row (and let's say 8 rows per page)
>> , that would leave approximately 800 bytes free per page (before any page
>> splits factor in) for updates, correct?
>Sounds right, I think...
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||cbrichards via SQLMonster.com wrote:
> So, if I have 800 bytes free per page (based upon 900 and some bytes per row),
> reducing the fillfactor to say, 80%, would not be that beneficial in reducing
> page splits due to updates, correct?
>
Probably not. You'll reduce the frequency of the page splits, but you
will still eventually encounter them. Your options are to monitor
fragmentation, reindexing when necessary, or consider clustering on
different keys that aren't so prone to splitting.
I have a script that you might find useful for handling the
fragmentation. I'm currently rebuilding my web site, and don't have the
script online, but you can pull it from Google's cache by searching for
"www.realsqlguy.com/twiki/bin/view/RealSQLGuy/DefragIndexesAsNeeded".
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Thursday, February 9, 2012
Affect of FillFactor on Index
I am trying to understand how the fillfactor might be affecting the clusered
index.
The primary key (nonclustered) on the table is a composite index of two (int
data type) fields, where one field is an identity seed incrementing by one,
and the other field being more constant.
The non-unique clustered index (that seems to fragment quite often) is a
composite index of four columns:
lname varchar(35)
fname varchar(35)
mname varchar(35)
rptype char(12)
This index has a fillfactor of zero.
The row size on the table is about 900 bytes.
The number of reads versus writes is about 50:1 under normal activity, but
sometimes (once every two weeks or so) this table is loaded with
approximately 200-500 new records at one time.
With a row size of 900 bytes, I am getting about 8 rows a page.
I am trying to wrap by brain around what affect updates and inserts have.
Please help explain.
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1cbrichards via droptable.com wrote:
> I am trying to understand how the fillfactor might be affecting the cluser
ed
> index.
> The primary key (nonclustered) on the table is a composite index of two (i
nt
> data type) fields, where one field is an identity seed incrementing by one
,
> and the other field being more constant.
> The non-unique clustered index (that seems to fragment quite often) is a
> composite index of four columns:
> lname varchar(35)
> fname varchar(35)
> mname varchar(35)
> rptype char(12)
> This index has a fillfactor of zero.
> The row size on the table is about 900 bytes.
> The number of reads versus writes is about 50:1 under normal activity, but
> sometimes (once every two weeks or so) this table is loaded with
> approximately 200-500 new records at one time.
> With a row size of 900 bytes, I am getting about 8 rows a page.
> I am trying to wrap by brain around what affect updates and inserts have.
> Please help explain.
>
With a fill rate of 100%, clustered on lname (assuming this is "last
name"), you're going to see page splits (i.e. fragmentation) any time
you insert a new last name between two existing ones. Example:
LNAME: Jenkins
LNAME: Jones
These are stored on a data page, that page is 100% full. You insert a
new record:
LNAME: Johnson
Due to the clustered index, this new record belongs between the two
existing ones. However, since the data page containing those records is
full, it has to be split to make room for the new record.
Does that help?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Thanks Tracy...that makes sense.
When it comes to updates, at 900 bytes per row (and let's say 8 rows per pag
e)
, that would leave approximately 800 bytes free per page (before any page
splits factor in) for updates, correct?
Tracy McKibben wrote:
>[quoted text clipped - 20 lines]
>With a fill rate of 100%, clustered on lname (assuming this is "last
>name"), you're going to see page splits (i.e. fragmentation) any time
>you insert a new last name between two existing ones. Example:
>LNAME: Jenkins
>LNAME: Jones
>These are stored on a data page, that page is 100% full. You insert a
>new record:
>LNAME: Johnson
>Due to the clustered index, this new record belongs between the two
>existing ones. However, since the data page containing those records is
>full, it has to be split to make room for the new record.
>Does that help?
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||cbrichards via droptable.com wrote:
> Thanks Tracy...that makes sense.
> When it comes to updates, at 900 bytes per row (and let's say 8 rows per p
age)
> , that would leave approximately 800 bytes free per page (before any page
> splits factor in) for updates, correct?
Sounds right, I think...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||So, if I have 800 bytes free per page (based upon 900 and some bytes per row
),
reducing the fillfactor to say, 80%, would not be that beneficial in reducin
g
page splits due to updates, correct?
Tracy McKibben wrote:
>Sounds right, I think...
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||cbrichards via droptable.com wrote:
> So, if I have 800 bytes free per page (based upon 900 and some bytes per r
ow),
> reducing the fillfactor to say, 80%, would not be that beneficial in reduc
ing
> page splits due to updates, correct?
>
Probably not. You'll reduce the frequency of the page splits, but you
will still eventually encounter them. Your options are to monitor
fragmentation, reindexing when necessary, or consider clustering on
different keys that aren't so prone to splitting.
I have a script that you might find useful for handling the
fragmentation. I'm currently rebuilding my web site, and don't have the
script online, but you can pull it from Google's cache by searching for
"www.realsqlguy.com/twiki/bin/view/RealSQLGuy/DefragIndexesAsNeeded".
Tracy McKibben
MCDBA
http://www.realsqlguy.com
index.
The primary key (nonclustered) on the table is a composite index of two (int
data type) fields, where one field is an identity seed incrementing by one,
and the other field being more constant.
The non-unique clustered index (that seems to fragment quite often) is a
composite index of four columns:
lname varchar(35)
fname varchar(35)
mname varchar(35)
rptype char(12)
This index has a fillfactor of zero.
The row size on the table is about 900 bytes.
The number of reads versus writes is about 50:1 under normal activity, but
sometimes (once every two weeks or so) this table is loaded with
approximately 200-500 new records at one time.
With a row size of 900 bytes, I am getting about 8 rows a page.
I am trying to wrap by brain around what affect updates and inserts have.
Please help explain.
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1cbrichards via droptable.com wrote:
> I am trying to understand how the fillfactor might be affecting the cluser
ed
> index.
> The primary key (nonclustered) on the table is a composite index of two (i
nt
> data type) fields, where one field is an identity seed incrementing by one
,
> and the other field being more constant.
> The non-unique clustered index (that seems to fragment quite often) is a
> composite index of four columns:
> lname varchar(35)
> fname varchar(35)
> mname varchar(35)
> rptype char(12)
> This index has a fillfactor of zero.
> The row size on the table is about 900 bytes.
> The number of reads versus writes is about 50:1 under normal activity, but
> sometimes (once every two weeks or so) this table is loaded with
> approximately 200-500 new records at one time.
> With a row size of 900 bytes, I am getting about 8 rows a page.
> I am trying to wrap by brain around what affect updates and inserts have.
> Please help explain.
>
With a fill rate of 100%, clustered on lname (assuming this is "last
name"), you're going to see page splits (i.e. fragmentation) any time
you insert a new last name between two existing ones. Example:
LNAME: Jenkins
LNAME: Jones
These are stored on a data page, that page is 100% full. You insert a
new record:
LNAME: Johnson
Due to the clustered index, this new record belongs between the two
existing ones. However, since the data page containing those records is
full, it has to be split to make room for the new record.
Does that help?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Thanks Tracy...that makes sense.
When it comes to updates, at 900 bytes per row (and let's say 8 rows per pag
e)
, that would leave approximately 800 bytes free per page (before any page
splits factor in) for updates, correct?
Tracy McKibben wrote:
>[quoted text clipped - 20 lines]
>With a fill rate of 100%, clustered on lname (assuming this is "last
>name"), you're going to see page splits (i.e. fragmentation) any time
>you insert a new last name between two existing ones. Example:
>LNAME: Jenkins
>LNAME: Jones
>These are stored on a data page, that page is 100% full. You insert a
>new record:
>LNAME: Johnson
>Due to the clustered index, this new record belongs between the two
>existing ones. However, since the data page containing those records is
>full, it has to be split to make room for the new record.
>Does that help?
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||cbrichards via droptable.com wrote:
> Thanks Tracy...that makes sense.
> When it comes to updates, at 900 bytes per row (and let's say 8 rows per p
age)
> , that would leave approximately 800 bytes free per page (before any page
> splits factor in) for updates, correct?
Sounds right, I think...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||So, if I have 800 bytes free per page (based upon 900 and some bytes per row
),
reducing the fillfactor to say, 80%, would not be that beneficial in reducin
g
page splits due to updates, correct?
Tracy McKibben wrote:
>Sounds right, I think...
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200608/1|||cbrichards via droptable.com wrote:
> So, if I have 800 bytes free per page (based upon 900 and some bytes per r
ow),
> reducing the fillfactor to say, 80%, would not be that beneficial in reduc
ing
> page splits due to updates, correct?
>
Probably not. You'll reduce the frequency of the page splits, but you
will still eventually encounter them. Your options are to monitor
fragmentation, reindexing when necessary, or consider clustering on
different keys that aren't so prone to splitting.
I have a script that you might find useful for handling the
fragmentation. I'm currently rebuilding my web site, and don't have the
script online, but you can pull it from Google's cache by searching for
"www.realsqlguy.com/twiki/bin/view/RealSQLGuy/DefragIndexesAsNeeded".
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Affect of deleting error messages
I'm using a unique index on a table with ignore_dup_key to get around using distinct in a stored procedure. In Query analyser, when I issue the stored procedure, you get a message and also the data in the Grid. In a stored procedure call, initiated from MS Access, the message means I have to put additional client side programming to work around it. I know that duplicate keys are ignored; that is why I've created the table with this feature (unique index in combination with ignore_dup_key). So what's with the message. If I delete the Error message 3604 will I still get an error message?I'm still trying to figure out when I would ever want to do this.
What are you trying to do?
From BOL
Controls what happens when an attempt is made to insert a duplicate key value into a column that is part of a unique clustered index. If IGNORE_DUP_KEY was specified for the index and an INSERT statement that creates a duplicate key is executed, SQL Server issues a warning and ignores the duplicate row.
If IGNORE_DUP_KEY was not specified for the index, SQL Server issues an error message and rolls back the entire INSERT statement.
The table shows when IGNORE_DUP_KEY can be used.|||I'm trying to use a server side solution to improve performance of a stored procedure. I've got a one-to many table with Street names (being the many) where the recno links back to the main table. It is possible for say King St to have a cross street of Kingsway. Hence Recno 13 for both. When I then match back to the main table I'd get multiple rows where I desire 1. To get around this I originally used the distinct clause. It works but is much slower than if I create a unique index with the ignore_dup_key option on a temp table. Problem being is the message. I've explicitly requested this action 'ignore_dup_key' so why tell me 'Duplicate key was ignored.' as if it is an error? We were force to a slower server and now my endusers are complaining about speed, that is why I wish to solve this server side instead of client side. I could write a routine to deal with the error client side but why go this route if I don't have too.|||Select Distinct
But you need to resolve this from a sql perspective...
did you read the quote...
You really should address handling MUCH more closely...you'r going to need to as well as have a general expectance of what the stored procedures are doing and what the expect...|||And that's not an error it's a warning...|||Similar to using a "set nocount" to eliminate an unwanted response to an end user. I'd expected and hoped an equivalent for eliminating an unwanted message from the use of a unique index. Yes I did read "SQL Server issues a warning and ignores the duplicate row" of your message. I wish to eliminate the message as it is unwanted. This is the contents of the message window in Query Analyzer "Server: Msg 3604, Level 16, State 1, Procedure ZZZStreet, Line 15
Duplicate key was ignored." The only way I can think of eliminating this is to delete the error message 3604 from the SQL Box. I've never done it and I am looking for guidance as to whether this will or will not fix the unwanted message from being given. I don't see any downside to this error being gone as the performance improvements should outweigh the loss of a strictly informational message. Maybe there is a downside that I'm unware of, an that's what I'm trying to figure out here.|||funny, I'm using EM here but when I create a table say Table1 with a varchar column (indexed, unique, ignore duplicate key) I am not able to insert duplicate values. From BOL it says: "Ignore duplicate key If you create a unique index, you can set this option to ensure each value in an indexed column is unique.".
Why am I confused?
What are you trying to do?
From BOL
Controls what happens when an attempt is made to insert a duplicate key value into a column that is part of a unique clustered index. If IGNORE_DUP_KEY was specified for the index and an INSERT statement that creates a duplicate key is executed, SQL Server issues a warning and ignores the duplicate row.
If IGNORE_DUP_KEY was not specified for the index, SQL Server issues an error message and rolls back the entire INSERT statement.
The table shows when IGNORE_DUP_KEY can be used.|||I'm trying to use a server side solution to improve performance of a stored procedure. I've got a one-to many table with Street names (being the many) where the recno links back to the main table. It is possible for say King St to have a cross street of Kingsway. Hence Recno 13 for both. When I then match back to the main table I'd get multiple rows where I desire 1. To get around this I originally used the distinct clause. It works but is much slower than if I create a unique index with the ignore_dup_key option on a temp table. Problem being is the message. I've explicitly requested this action 'ignore_dup_key' so why tell me 'Duplicate key was ignored.' as if it is an error? We were force to a slower server and now my endusers are complaining about speed, that is why I wish to solve this server side instead of client side. I could write a routine to deal with the error client side but why go this route if I don't have too.|||Select Distinct
But you need to resolve this from a sql perspective...
did you read the quote...
You really should address handling MUCH more closely...you'r going to need to as well as have a general expectance of what the stored procedures are doing and what the expect...|||And that's not an error it's a warning...|||Similar to using a "set nocount" to eliminate an unwanted response to an end user. I'd expected and hoped an equivalent for eliminating an unwanted message from the use of a unique index. Yes I did read "SQL Server issues a warning and ignores the duplicate row" of your message. I wish to eliminate the message as it is unwanted. This is the contents of the message window in Query Analyzer "Server: Msg 3604, Level 16, State 1, Procedure ZZZStreet, Line 15
Duplicate key was ignored." The only way I can think of eliminating this is to delete the error message 3604 from the SQL Box. I've never done it and I am looking for guidance as to whether this will or will not fix the unwanted message from being given. I don't see any downside to this error being gone as the performance improvements should outweigh the loss of a strictly informational message. Maybe there is a downside that I'm unware of, an that's what I'm trying to figure out here.|||funny, I'm using EM here but when I create a table say Table1 with a varchar column (indexed, unique, ignore duplicate key) I am not able to insert duplicate values. From BOL it says: "Ignore duplicate key If you create a unique index, you can set this option to ensure each value in an indexed column is unique.".
Why am I confused?
Subscribe to:
Posts (Atom)