Dear all,
I am not be able to delete a row in the following table:
if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblSysRights]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[tblSysRights]
GO
CREATE TABLE [dbo].[tblSysRights] (
[sinRightID] [smallint] IDENTITY (1, 1) NOT NULL ,
[sinUserID] [smallint] NOT NULL ,
[sinApplicationID] [smallint] NOT NULL ,
[sinType] [smallint] NULL
) ON [PRIMARY]
GO
No indexes. No constraints. No relationships. What on earth hell is happenin
g?
SELECT *
FROM tblSysRights
WHERE (sinUserID = 61) AND (sinApplicationID = 163)
725 61 163 null
725 61 163 null
I obtain a warning which tell me:
"key column information is insufficient. too many rows affected"
Thanks in advance and best regards,Set RowCount 1
Delete
FROM tblSysRights
WHERE (sinUserID = 61) AND (sinApplicationID = 163)
Set RowCount 0
Madhivanan|||Enric,
> I am not be able to delete a row in the following table:
Can you be more specific?
From where and how are you trying delete the row?
AMB
"Enric" wrote:
> Dear all,
> I am not be able to delete a row in the following table:
> if exists (select * from dbo.sysobjects where id =
> object_id(N'[dbo].[tblSysRights]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
> drop table [dbo].[tblSysRights]
> GO
> CREATE TABLE [dbo].[tblSysRights] (
> [sinRightID] [smallint] IDENTITY (1, 1) NOT NULL ,
> [sinUserID] [smallint] NOT NULL ,
> [sinApplicationID] [smallint] NOT NULL ,
> [sinType] [smallint] NULL
> ) ON [PRIMARY]
> GO
> No indexes. No constraints. No relationships. What on earth hell is happen
ing?
> SELECT *
> FROM tblSysRights
> WHERE (sinUserID = 61) AND (sinApplicationID = 163)
> 725 61 163 null
> 725 61 163 null
> I obtain a warning which tell me:
> "key column information is insufficient. too many rows affected"
> Thanks in advance and best regards,
>
>|||Thanks for that Madhinavan.
Done successfully.
Thanks Alejandro, too.
Regards,
"Alejandro Mesa" wrote:
> Enric,
>
> Can you be more specific?
> From where and how are you trying delete the row?
>
> AMB
>
> "Enric" wrote:
>|||Just to add a couple of points. For elimination of duplicates, refer to:
http://support.microsoft.com/defaul...b;EN-US;q139444
Use keys in all your tables, and you will avoid a lot of such headaches. On
a related note, a couple of comments:
* You seem to have an identity column which is constrained to be unique, but
apparently it seems to be violated with SET IDENTITY_INSERT ON setting.
Check where the "hole" is.
* Your naming conventions are stale which can be better -- search for some
good guidelines in the archives of this newsgroup.
* Use Query Analyzer for testing your queries, the EM query interface is
buggy and has certain limitations.
* And most importantly, use primary keys in your tables. In relational
database, a value is identified using <table, column, key> triplet. With
duplicates, such identification becomes impossible and relational operations
cannot be used beneficially. The impossibility of logically deleting one row
out of duplicates is often cited as a prime illustration of the consequence
of allowing duplicates by SQL. ( SQL language inventors and its flag bearers
should take the credit, for even standardizing them ! )
Anith|||Thanks for that Anith.
That table was defined without identity fields or key. Just a mess-up.
Best Regards,
"Anith Sen" wrote:
> Just to add a couple of points. For elimination of duplicates, refer to:
> http://support.microsoft.com/defaul...b;EN-US;q139444
> Use keys in all your tables, and you will avoid a lot of such headaches. O
n
> a related note, a couple of comments:
> * You seem to have an identity column which is constrained to be unique, b
ut
> apparently it seems to be violated with SET IDENTITY_INSERT ON setting.
> Check where the "hole" is.
> * Your naming conventions are stale which can be better -- search for some
> good guidelines in the archives of this newsgroup.
> * Use Query Analyzer for testing your queries, the EM query interface is
> buggy and has certain limitations.
> * And most importantly, use primary keys in your tables. In relational
> database, a value is identified using <table, column, key> triplet. With
> duplicates, such identification becomes impossible and relational operatio
ns
> cannot be used beneficially. The impossibility of logically deleting one r
ow
> out of duplicates is often cited as a prime illustration of the consequenc
e
> of allowing duplicates by SQL. ( SQL language inventors and its flag beare
rs
> should take the credit, for even standardizing them ! )
> --
> Anith
>
>
Robert Varga wrote:
