Instead of putting the ORDER BY on the statement that inserts into BB_HOLB999, you need to put it onto the statement that retrieves from BB_HOLB999. So in the example you gave...

create table BB_HOLB999 (

SYST varchar (10),

CREF decimal (10),

BDAT decimal(7,0))

go

create unique clustered index BI on BB_HOLB999(CREF,syst) with ignore_dup_key

go

insert into BB_HOLB999

select 'OSCAR' as [syst], CREF, bkbdat

from BB_TABLE join refdata.dbo.TDFBK on CREF=BKCREF

where BKCOST > 0

and BKPAX > 0

and BKINV1 > 0

and BKLINK is NULL

and bktype is NULL

and BKBSTS = ''

and BKLAPD is null

and BKBDAT<dmat

and (BKDEPT in ('20','23','16','50','10','40','52','80')

or (BKDEPT ='30' and BKPROD in ('Qp','39','8p','8q','8r','8s','8t','8u','8v','8w','8x','1A','9d','X2','AG','AH','AF','AI','6N','6A','8N','V1','U1')))

go

select *

from BB_HOLB999

where CREF='8458923'

ORDER BY BDAT DESC

go

As for why it worked on SQL 2000, luck probably more than anything. The whole SQL architecture changed quite a lot between 2000 and 2005 and there were a lot of things that changed. The order of results has never been guaranteed without an order by. If SQL 2000 behaved in a certain way, that's by chance and not a feature of the DB engine.