I'm not a SQL server expert by any means, and I'm hoping this is something simple. The scenario: I create a new database with all the defaults, then add a table with a primary key and two nvarchar(max) fields, but I forget to set the identity specification on the key so I go back and try to change it the IsIdentity property from No to Yes and I get the following error:
Found this after posting my question - leaving up to moderators to decide if this is something to keep or not...
The simplest way to bypass this error is to go into Option – Designers and uncheck the option Prevent saving changes that require table re-creation.
Related
I am struggling with this specific problem for hours. Hopefully someone can help me on this.
As the question described above, I have a tabular form which is built from a table, which has a primary key ('ID') set as "Identity Always". This became a problem for the tabular form, because whenever I made changes to the data and click on 'Save', Apex will display this error: ORA-32796: cannot update a generated always identity column
I tried several workaround such as ROWID, but this solution would not work because I need to join the tabular form with fields from other tables to display additional info - hence the ROWID would not be preserved and could not be used as primary key.
I also read in an Apex documentation that:
Utilizing the IDENTITY clause on a table can have an impact on
Application Express applications. An error will be raised by the
database if an IDENTITY column, with ALWAYS parameter specified, is
included in an INSERT or UPDATE statement. The Application Express
Builder has been enhanced to allow the specification of the identity
clause within the Create Table Wizard. The Create Form wizard will
generate a "Display Only" item for an identity column with the ALWAYS
parameter.
Which I do not understand. Apex indeed generated an extra column ('ID_Display'), but it does not change the fact that my tabular form still throw the same error (ORA-32796 above). How is this "Display Only" item can save me from the "cannot update a generated always identity column"?
As a side note, I am developing in apex.oraclecorp.com, Apex as a service, where I cannot access the files or made SQL alteration to my table. Please let me know if you encountered this problem before and found a solution - thanks in advance!
P.S. the Apex version is 5.0.4.
EDIT:
Sorry, I just realized there is the SQL Command UI to perform SQL operation in Apex. Anyone knows how to ALTER the identity of a table from ALWAYS to DEFAULT?
So I'm sure this is more of a workaround than an actual understanding of the issue and solution, but in the wizard, I found that:
when you are in 'Form Attributes' in the wizard setting as follows:
Primarky Key Type: Select Primark Key Column(s)
Primary Key Column: 'Your column'
Primary Key Column: (I didn't have anything to enter here)
Primary Key Source Type: 'Existing Trigger' (This seemed to allow the Identity column do it's thing on the table/form I was working on.). I had been running into the same issue with I would change this to 'Existing Sequence'.
If you ever figured this out, I would love to know the details.
More reading is required, but it's something...
The following solved the ORA-32796 insert problem for me with Editable Interactive Grid. I suppose the same works for tabular forms.
Goto Page Designer for the page in question.
Click on "Processing", or click on "Component View" and then click on the process under "Page Processing". For Editable Interactive Grid, it is the process "Save interactive Grid Data".
Click on "Yes" in the "Return Primary Key(s) after insert" section in properties.
Click save/run.
ALTER TABLE t MODIFY c GENERATED BY DEFAULT as IDENTITY;
After experimenting with this considerably it appears that the only option, if you want to use the Identity clause to generate a sequential numeric primary key, is to use
BY DEFAULT ON NULL AS IDENTITY
as Apex will attempt to insert a null value into the ID Field when doing automatic row processing. Neither of the 2 other options to work correctly with Apex in this circumstance.
The other options are:
1. Create a sequence and a trigger, which does not present any problems with Apex
2. Use a guid for the primary key
I am able to do this in SSMS. I want to do this in SSOE in VS13.
Things to check:
If table has already been created, SSMS is default-set to prevent changes like that (which actually drop and re-create the table behind the scenes). If this is the case with you, in SSMS go to Tools -> Options -> Designers -> uncheck "Prevent saving changes that require table re-creation"
If it's a new table (or you've already done the above), make sure the column in question is of type "int". By default, SSMS sets a new column (even one that ends with "ID") to be nchar(10), which can be misleading.
View the table in Designer mode, right click and try set identity. good luck.
I couldn't set the primary key column as the identity in SSMS because the column had a default value. Removing the default value enabled setting the identity specification for me.
The database that I am tasked with fixing has a table with an identity column/PK that has a datatype of BigInt. This causes problem with the Access front end in that a datasheet to this linked table will not allow edits to the records. (This is a known issue with ODBC drivers and Access)
The table's Id column should never have been created as a bigint in the first place but that is a moot point now. I need to convert or recreate this column with a datatype of int, without losing the existing data.
There are ~2 million records in this table.
There are an unknown number of apps and Access apps that access this table so I am trying to do this as smoothly/stealthily as possible since the likelihood of finding all of those apps and modifying them before I make the change is slim.
Any thoughts or ideas?
I'm assuming the IDENTITY column is your PRIMARY KEY, and it's probably clustered :) MY advice below is based on those assumptions.
If you've only got a few indexes on the table, and the PRIMARY KEY is only referenced by a few FOREIGN keys, you should be able to change the datatype by:
Dropping any nonclustered indexes which contain the IDENTITY value.
Dropping the FOREIGN KEY constraints which point to the PRIMARY KEY.
Drop the PRIMARY KEY
ALTER TABLE tablename ALTER COLUMN columnname INT;
REcreate the PRIMARY KEY
Re-enable the FOREIGN KEY constraints with CHECK.
Recreate your nonclustered indexes.
As RBarryYoung pointed out, a lot of this can be scripted out by the SSMS GUI (if it's configured to allow saving changes), but the difference is that the GUI will create a temporary table, move your data, rename the new table to the old name, and drop the original.
Here's how to do it from Management Studio(SSMS):
First, make a backup copy of your database. If you make a mistake, or something unexpected happens, the easiest way to fix it is to restore from backup.
In the SSMS Explorer Pane, navigate to the table, then right-click on it and click "Design".
Select the Identity column's row and change it's datatype to "INT".
Save your changes, ignore the warning.
If you need a script instead, then replace step (4) above with:
Click the Script Changes button. Ignore the warning and then copy the script into you paste buffer. Make a new query window and paste the script into it. Then close the design window, cancelling any changes.
As Stuart Ainsworth points out, in later versions of SQL Server, it may prevent you from doing this, with a warning about "Dropping a Table". To fix this in SSMS, click the Tools..Options menu entry, then go to the "Tables and Designers" pane under "Designers" and uncheck the "Prevent saving changes that require table recreation" option.
I've got a SQL Database Table, which has 35 existing records. One of the fields in this table is called Name, nvarchar(100), not null
However, due to a recent change, I need to make this column nullable.
When I change the column to allow nulls in SQL Server Management Studio, and go to save my changes, I get the following error:
Saving changes is not permitted. The changes you have made require the
following tables to be dropped and re-created
How can I allow this to automatically be dropped and re-created?
I've found the solution. Go to "Tools > Options > Designers > Table and Database Designers":
It's a setting in SSMS.
Tools - Option - Designers - Prevent saving changes that require table re-creation
I had the same problem; wanting to Allow Nulls for a column that previously did not. Consider MS's warning to NOT turn off this option:
http://support.microsoft.com/kb/956176
And their recommendation to use Transact-SQL to solve the problem, e.g.
alter table MyTable alter column MyDate7 datetime NULL
This solved it for me.
I create 2 tables and another 1 with foreign keys to the other two.
I realized I want to make some changes to table no 3.
I try to update a field but I get an error "Saving changes is not permitted. The changes you have made require the following table to be dropped and re-created."
I delete those 2 relationships but when I look at dependencies I see my table still depends on those 2 and I still cannot make any change to it.
What can I do?
You can also enable saving changes that require dropping of tables by going to "tools->options->designers->Table and database designers" and unchecking "Prevent saving changes that require table re-creation"
Be careful with this though, sometimes it'll drop a table without being able to recreate it, which makes you lose all data that was in the table.
When using Microsoft SQL Server Management Studio 2012, the same message occurs.
I used the script feature to do modifications which can be seen as a rather good workaround if you wanna use the designer only within a "safe" mode.
Especially the GUI related to create a foreign key is not the best in my opinion. When using a script (alter table) for adding a fk, you are faster than using this GUI feature.
When adding/writing a 'not' in prior to null, that's not a hard issue. (Removing an 'Allow Nulls' for a column refers to "Saving changes is not permitted" when using the designer.)