>>>Hi,
>>>
>>>I need to change the type of a PK column of a table from type NUMERIC (6,0) to INT (When I created this table I never thought that the number of records would grow to be more than 999,999 but now I need more).
>>>
>>>When I change the type in the SSMS it works, but it takes quite a bit of time on a table of about 600,000 rows. I thought that changing the type using the script would be faster. And I tried the following script:
>>>

>>>ALTER TABLE dbo.MyTable
>>>ALTER COLUMN wo_number INT 
>>>

>>>
>>>But I get the following errors:
>>>

>>>he object 'PK_MyTable' is dependent on column 'wo_number'.
>>>Msg 5074, Level 16, State 1, Line 1
>>>The index 'open_wo' is dependent on column 'wo_number'.
>>>

>>>That is, the PK index and another index do not allow the script to change the type. Does it mean that the only way to change the type of this PK is via SSMS?
>>
>>Just FYI, rather than having different sizes of primary keys, just use Int for every primary key. Don't forget to start the numbering at -2 billion. The primary key is not supposed to have any meaning to anyone. Candidate keys might have meaning, but are not used for joining. Further, you'd never have run into this problem.
>
>Mike, you're describing a practice, not a universal rule.
>
>There is absolutely no technical reason why PKs should be meaningless. In fact Date, Codd and Celko all have different takes on the matter.
>This also applies, to candidate keys. They perfectly can be used for joining and in fact is very common in systems where information is held that links to other systems / databases. For example a passport number could be a candicate key, but that same number could be a primary key in another table in the same or other database whos definition is beyond your control
>
>OTOH, we also use the 'practice' of using meaningless int fields as PKs and they indeed avoid a lot of problems. OTOH, it does not make any other 'practise' against the relational model or even bad practice.
>
>Walter,

True, but as soon as you write a trigger and try to join
INSERTED and DELETED tables as you do it?