Using bugs in SQL2K descending index

Resolves a bug that is updated or deleted using contrast criteria on SQL2K Descending index I've tried both SQL Server Enterprise and personal, every time. ：(
See my replies in detail:
There are indeed no problems with SQL Server 7.0, in SQL 2000 (Enterprise and personal versions are available),
Table to have a clustered index, and the order of the indexes is descending,
For example, tables created by the following DDL SQL
CREATE TABLE [Atype] (
[AID] [INT] Not NULL,
[Name] [varchar (20)] Not NULL,
CONSTRAINT [Pk_datetype] PRIMARY KEY CLUSTERED
([AID] DESC) On [PRIMARY],
) on [PRIMARY]
After adding some data, AID is distributed between 1-100
INSERT into [Atype] VALUES (1, ' a ')
INSERT into [atype] VALUES (' B ')
INSERT into [Atype] VALUES (M, ' C ')
Do
Select from Atype where Aid < 50
Go
Delete from Atype where AID < 50
Go
Select from Atype where Aid < 50
The last query still has record output. :(
By Yee Red Childe
Reports have been sent to the MSSQL development team, who acknowledge the error.
Before the new patches come out, the following suggestions are given:
Do not use descending indexing on a single column, because this does not have a performance benefit, just omit the order by field Desc A few words, with a QA show plan to see that, regardless of whether there is a orders by or whether ASC or DESC, Does not have this overhead (on a clustered index).
Descending indexes are generally used for composite indexes, which may be the cause of this bug.
Original:
Note this there is no need to create a descending index on a single column because SQL Server can traverse
An ascending index backwards when appropriate. Descending is normally used the only in composite indexes.
This is probably why the bug surfaces