can't alter column to NOT NULL

If I run the following 3 statements (on sql server 2000):
create table foo (x nvarchar(128))
create unique index ix_foo on foo (x)
alter table foo alter column x nvarchar(128) not null
I get this error:
Server: Msg 5074, Level 16, State 8, Line 1
The index 'ix_foo' is dependent on column 'x'.
Server: Msg 4922, Level 16, State 1, Line 1
ALTER TABLE ALTER COLUMN x failed because one or more objects access this
column.
Looking in the documentation it says "The altered column cannot be...Used in
an index, unless the column is a varchar, nvarchar, or varbinary data type,
the data type is not changed, and the new size is equal to or larger than
the old size."
Since the column is nvarchar, the data type is not changed, and the new size
is equal to the old size, this should be allowed.
Is the documentation just wrong or have I misunderstood something?
AndyAndy Fish wrote:

> Since the column is nvarchar, the data type is not changed, and the
> new size is equal to the old size, this should be allowed.
> Is the documentation just wrong or have I misunderstood something?
You need to drop the index, alter the column and then recreate the
index, that's the only way.
HTH,
Stijn Verrept.|||Disable the foreign key constraints / drop them. Alter the table (make
sure there are no NULL values in there). Activate recreate the foreign
key relationship.
HTH, Jens Suessmeyer.sql

Cant add bit column to unique index

This is for SQL 2000 (SP 2) using Enterprise Manager. I have a table with a unique index comprised of several int fields. The index needs to include an additional bit field that is part of the table. But when I go to modify the index, the bit field name doesn't appear in the Column Name list.

Can anyone shed any light on the problem?

Thanks.

You can not create index on BIT data type and that's the reason you can not see column.|||

Where can I find documentation on that? Why is that restriction in place?

|||

JigneshP, you definitely can create a unique index using bit fields. I was able to do it via TSQL in Query Analyzer. Here's the sql I used:

DROP INDEX [dbo].[Material].IX_MaterialCREATE UNIQUE INDEX [IX_Material]ON [dbo].[Material] ([MaterialID], [MyBitField])ON [PRIMARY]GO

The bit field is MyBitField. I then verified the index works by inserting data that duplicated another row except for the bit field.

I'm still looking for someone to tell me why I can't add the bit column to an index via Enterprise Manager.

|||

I found this link (http://sqlserver2000.databases.aspfaq.com/can-i-create-an-index-on-a-bit-column.html) that shows how to do it via Enterprise Manager. You have to do it from the Tasks menu / Manage Index.

|||Oh Thanks ZLA. Sorry about that.

Cannot see index in Object Explorer on Replicated Database

I have replicated all the tables from the Business Data database to my instance of SQL Server 2005. They did not create primary keys on the tables, so I am adding them on the replicated database. I was trying to save one of the tables after adding a new primary key and got this error message:

'BuildingValues' table
- Unable to create index 'PK_BuildingValues'. CREATE UNIQUE INDEX terminated because a duplicate key was found for object name 'dbo.BuildingValues' and index name 'PK_BuildingValues'. The duplicate key value is (2). Could not create constraint. See previous errors. The statement has been terminated.

The problem is that there is nothing displayed in the Indexes folder for this table in Object Viewer (or any of the other folders for this table), so how would I know an index already existed? The index shows up for this table on the Publisher database, but not the Replicated database. Is this normal?

Sounds like you only replicated the data over without transfering other objects (i.e. pk, constraints, indexes, etc.). The error here is that your current data is not qualified for a pk constraint - pk creates an unique key/constraint underneath, thus, the values cannot be duplicated.
To find the dupes, try:
select [your_pk_col]
from tb
group by [your_pk_col]
having count(*)>1
Resolve that and you should be able to create your pk.
Indexes should get created on the subscriber if you configure it during publication creation - go to the object properties.|||

Thank you very much for your answer. The articles at the Publisher were configured to replicate all the keys and constraints to the Subscriber. You were right about the cause of the problem. The index could not be created, because of duplicate values in the column on the Subscriber. Once I added another column to make it unique, the primary key worked fine. Thanks again.

Cannot resolve index for fact table

Hi,

When I am trying to deploy or save the project with cube I am getting this error.

Property accessor 'StorageLocation' on object '339f70f7-5d30-4c38-97c8-30b675640b24' threw the following exception:'Cannot resolve the 'Fact Table 2' index because the setting does not support the '2' nesting level.
Make sure that the product is installed properly.' (Microsoft Visual Studio)

Also I have this error in "StorageLocation" property for partition.

Any ideas?

Thank you for your help.

One idea is double check the value for the StorageLocation property. What value did you have for it.
Make sure it points to the valid folder on server's file system.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.