This may be a dumb question, but why can't I change the Identity Specification or (Is Identity) from 'No' to 'Yes'?
Check your column data type.
If it is varchar then you can't change identity column.
To change identity column, it should have int data type.
You can disable the Option "prevent saving changes that require table re-creation"
but this is strongly unrecommended by msdn.
to do so go to:
Tools -> Options -> Designers
There uncheck: "prevent saving changes that require table re-creation"
You cannot change the IDENTITY property of a column on an existing table. What you can do is add a new column with the IDENTITY property, delete the old column, and rename the new column with the old columns name.
Of course, what happens then (for some people) is that they don't like the fact that the new column appears "at the end" of the list of columns (even though you shouldn't care about the positions of columns - you should always be using their names). In that case, you need to do the same trick, but at a higher level - create a new table (with the column definition altered), copy data from the old table to the new, drop the old table, and rename the new one.
I thought SSMS still tried to pretend that it was possible, by doing the second trick behind the scenes.
Also check to make sure that there isn't a default value or binding on the column.
Remove Default Value or Binding.
Following on from Damien_The_Unbeliever's comment above, you can edit the column order in Visual Studio's design interface.
I've managed to do this successfully. To confirm, the steps are:
Add a new column with the IDENTITY property
delete the old column,
Rename the new column with the old columns name.
(Optional) Re-order columns to have the IDENTITY column from Visual Studio.
The solution that worked for me was to change the Data Type to int from its default nchar. Additionally, I had to refresh my database server connection to get it working.
As you can see the yes value for the identity specification is disabled so the other answers above is not applicable for me but following Joy's answer, I saw that I really had a Default Value or Binding. I just omitted the default value and everything i neede was enabled.
Took me a while to find the solution to this, at first I was trying to find a way to change a value from here (it's yes cause I was able to change it using the next way)
But then by right-clicking -> properties -> Table designer -> Choose Identity column
Doing this made the "Identity Specifiacation" to "Yes"
I think Firstly you have to check the (isIdentity) checkbox after that you can able to check the Identity Specification Checkbox
Related
Regarding:
MS Access 2016
SQL Server 2017
I have an ODBC connection to a local SQL Server. Works like a charm. Two of the linked tables are made as views. When I open the view in MS Access, it shows figure 1. When I apply a filter, I get the results shown in figure 2, with error in all fields as #Name?
It works perfectly fine when I look it up directly in SQL Server.
Any suggestions?
Add what is called a "row version" column to the table.
So, create a timestamp column in the base table that the view is based on. Now include that new column - useally I call it TS, but it is going to be of type "timestamp" - not to be confused with a date/time column.
The table likely has 1 or more floating point columns, or perhaps a timestamp column. So, add the timestamp column to the base table. Add the TS column to the view, and then re-link the view (or refresh -don't forget this last step).
When you link the view (manually with the access UI), you are given a one-time chance to select the PK column. You should not necessary need to set (choose) the PK column, but if you don't, then the table will be read only (and that is fine).
If above TS column does not fix this, then do try choosing a PK when you link (so, a refresh will not suffice, you have to delete and re-create the linked view to get (force/trigger) that all important prompt for the PK. As noted, adding a TS column should fix this, but if it does not, then start over, and re-create the linked view with both a PK selected, and also that all important TS column. If you don't include the TS column, then Access (client side) will do a ugly field by field compare - using a TS column will eliminate this extra work, and rather likely your issue.
I have an SQL Server table structure where in some columns are foreign keys that refer to different look up tables. These columns are created as NOT NULL and with DEFAULT value = 1 as the look up value for ID = 1 is the default value I want to assign in case NULL is passed while saving a record.
However, I got below error while trying to Add/Update/Delete records of this child table.
An attempt was made to remove a relationship between a (*) and a (*). However, one of the relationship's foreign keys (X) cannot be set to null.
I tried to search a lot but I got solution to change LINQ to SQL code or XML manually for resolving this. I cannot do that because in future when ever the table gets changed, I'll have to make sure the manual change is applied every time.
Also, I can not change my columns to accept NULL because that will impact other applications using the same table through LINQ To SQL.
I need more manageable solution for this.
I assume that you are trying to "reset" a reference to its default value by assigning null to it, expecting L2S to adopt the database default. However, as for L2S, you're only nullifying a foreign key. It's not aware of any defaults in the database.
So you have to change the reference by setting it to the default lookup object yourself. You could do that by adding a Reset() method to your classes, so you don't have to scatter this code all over the place.
I got this resolved by assigning default values to the Table class properties from Code it self. What I understood is this. LINQ to SQL does not take into consideration the default value set from the DB. Also, the column is NOT NULL. So being INT columns the default value that .NET assigned was 0 to these properties. Now, I don't have any master entry with ID = 0 in my database. Also, since the DB did not get a NULL value for this column, it does not attempt to apply the Default value at all.
So what I did was, before saving the record, if I find that if the control which is bound to this property is having a NULL value (Nothing is selected/ control is invisible etc) I assign the Default value from the code it self. This eliminates the need to fall back on the database to assign the default.
Now, everything is working fine. Thought to share this as I could not get any satisfactory answers from anywhere.
I used the following SQL script to enable setting current time in a field, when a new row is added to a table:
ALTER TABLE [Items] ADD CONSTRAINT DF_Items DEFAULT GETDATE() FOR [CreationDate]
Now I am using Entity Framework to work with this table, and add new rows to it. What I want to do is allow that specific column to receive its value from SQL Server itself, and not have to provide the value myself.
Setting that specific column's value to Nothing in Visual Basic fills the field with DateTime.MinValue, which is not what I want (and SQL Server doesn't support, by the way).
What changes do I have to make to make this work?
You must set StoreGeneratedPattern in EDMX designer (or DatabaseGeneratedOption in code first) to Identity for that date property. EF always sends .NET default value for not filled property which is not store generated. Setting the pattern to Identity will tell EF that value is generated in DB during insert and it will requery its value. If you change the pattern from default value you will not be able to set the property in your application.
I am doing some homework. The users of my database uses some other attributes, not just the ones that ASP 2.0 automatically created for me when i implemented the login and registration mechanism. But when i try to save the modification displays me an error. Can someone give me a hand?
This is the error:
The error says:
'aspnet_Users' table
- Unable to modify table. ALTER TABLE only allows columns to be added
that can contain nulls, or have a
DEFAULT definition specified, or the
column being added is an identity or
timestamp column, or alternatively if
none of the previous conditions are
satisfied the table must be empty to
allow addition of this column. Column
'kjoptekvoten' cannot be added to
non-empty table 'aspnet_Users' because
it does not satisfy these conditions.
That database was automatically created when i implemented Forms based authentification and registration. The problem now is that that users needs some more attributes. How can i give to it more attributes? What is the easiest way to do it?Does not mind if it is not theorically correct(It is just for a homework).
I would appreciate a lot your help.
Apart form the technicalities on the database side, there is a deeper issue here.
You should not alter the aspnet_Users table because you are bypassing the way the membership 'system' in asp.net is working. Instead, have a look into the Profile mechanism: https://web.archive.org/web/20211020111657/https://www.4guysfromrolla.com/articles/101106-1.aspx
You need to make the new attributes nullable or provide a default value. But you also need to consider how to obtain the values from db. The sql membership provider utilizes an auto generated stored procedure to put data into the membership user instance returned,so just adding the attributes in the table will not be sufficient to get the attribute values to your application. I would use a user attribute table instead.
The error message says it all:
You are adding a new column that can't be Null (checkbox "Allow Nulls" not checked), but as you didn't provide a default value, it will be Null.
So SQL Server can't create the new column.
You can do two things:
a) Create the new column with Nulls allowed.
THEN put a default value in all existing rows:
update aspnet_Users set kjoptekvoten = 0)
...and THEN uncheck "Allow Nulls"
b) Create the new column directly with default values.
I don't know if you can do this in Management Studio, but it's easy in T-SQL:
alter table aspnet_Users
add kjoptekvoten int not null
constraint Name_For_Constraint default(0) with values
This will add the new not nullable column, AND create a constraint with a default value, AND fill the default value in all existing rows (SQL Server will not do this without the "with values" clause).
Normally I just set the column as allow nulls
then do an SQL UPDATE TABLE SET VALUE = whateva
then update the table definition to not allow nulls.
Why does SQL 2008 all of a sudden want to drop my tables when I go to change the column type from say int to real? This never happened in SQL 2005 to my knowledge. Any insight would be helpful please.
I can't believe the top answer has been sitting here for so long - it is very dangerous advice!
There are few operations that you can do inplace without dropping your table:
Expand a varchar column https://dba.stackexchange.com/questions/5211/changing-column-width
Make a column nullable (but not vice-versa)
Renaming columns using sp_rename
If you find yourself in the situation where altering a column is not possible without dropping the table, you can usually use a SELECT INTO query to project your data into a new table, then drop the old table (temporarily disabling constraints) and then renaming the projected table. You will need to take your database offline for maintenance in this case though.
In SQL Server 2008, go to Tools >> Options. In the little window, click "Designer". Uncheck "Prevent saving changes that require ..."
=====
Edited on Sept 4th, 2015.
I have added this answer here a long, long time ago describing the way I would solve the situation described on the question above. Since then, users on the threads below have exposed several concerns on doing things the way I recommended at the time. Basically, the solution I described could be problematic on some scenarios. I then suggest you to keep on reading to check other users' comments and pick the best solution for you.
Here is what I use:
-- Add new column
ALTER TABLE MyTable
ADD Description2 VARCHAR(MAX)
GO
-- Copy data to new column (probably with modifications)
Update MyTable
SET Description2 = Description
GO
-- Drop old column
ALTER TABLE MyTable
DROP COLUMN Description
GO
-- Rename new column to the original column's name.
sp_RENAME 'MyTable.Description2' , 'Description', 'COLUMN'
GO
Copy the data into a new column.
Drop the old column.
Rename the new column to the old column's name.
I have the same issue. Athough my account has sa rights if I try using another sa account it works. It seems that somehow my account does not have the ability to alter. still investigating, but it is a permission issue.
update:
I cannot expain it. but this is what I did. there two domain groups my account belonged to. One was a new AD domain group and the other was an NT legay domain group. Once I removed the legacy domain group I was able to alter the table successfully. Mind you both groups had "sa" priviliges.
The behavior was that the alter commands would result in success, but nothing changed on the table. Then when I manually tried to change the fields through the designer it complained that I was not allowed to make change if it required to drop and recreate the table. I found the setting in tools and I was able to turn that off. But this table is huge and not a good idea to do this. I woud advise others against it.
so it was a permission issue. I can't explain how, but I hope it helps someone else
Another way to this without totally dropping the table is
Take a backup of the column values.
Make the column nullable if it does not already allow nulls. Set the column values to be null by
doing
update tablename set columnname = null
Delete the column
Insert a new column with the same name as the deleted column and the type which you want
Insert the saved data into this column