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
Related
I am running SQL Developer Version 18.1.0.095 on a MacBook Pro. Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
I’ve encountered an issue regarding sequences and triggers which seems unusual and I’d like to know if it’s a bug.
If you use SQL Developer to create a table, and visit the identity column tab on the table properties screen, to set up auto incremented Primary Key values via an auto generated sequence and trigger pair, everything works fine in terms of auto generated values. But if you ever come back to the table and add an additional column, the identity column value is set back to 'none' (silently, in the background) and the database returns 'cannot insert NULL' type errors because there is no longer an auto generated value being created for the column identified in the trigger. It may also be the case that if you reset that drop down, duplicate triggers and sequences are created. eg triggername1, triggername2.
If you manually create a sequence and trigger pair for a given table, there is no issue with adding extra columns later in the table's life (which seems more reasonable). It may that standard workflow requires you to archive and recreate tables each time you add a new column, but this seems a lot of work and a less desirable outcome than just being able to add columns without any impact on a primary key column. So this makes me wonder which is the default behaviour and if the resetting of triggers via the identity column workflow is a bug.
For now I’ll stick with manual sequences and triggers but I’m interested to know more about this.
I am new to SSIS packages and just require assistance on how to transfer data from one data source onto my own database.
Below is my data flow:
Now I have a ODBC Source (Http_Requests Source) where I take data from a PostgreSQL database table (see screenshot below for table columns and data):
Below is the OLE DB destination where it has the table I want to transfer the data to (this table is currently blank):
Now I tried to start debugging to extract the data but I get a few errors (displayed below):
I am a complete novice so I would like some guidance on what I need to include in order to get this SSIS package to transfer data across. Would I need to include a merge statement and how do I apply it. I heard you can write a merge as a proc and call on the proc as a sql command. Does that mean I will need to write a proc in SSMS and then call on it within the OLE DB Destination?
If somebody can provide an example and screenshot then that would be very helpful as I am really new to SSIS.
Thank you,
Check constraint on destination table or disable them before running it.
Below are query you can use.
-- Disable all table constraints
ALTER TABLE YourTableName NOCHECK CONSTRAINT ALL
-- Enable all table constraints
ALTER TABLE YourTableName CHECK CONSTRAINT ALL
Tick keep identity
box or drop primary key on the table. After you apply the changes do not forget to refresh metadata by opening the mappings in sis.
the error means that PerformanceId is an IDENTITY column on your destination table. IDENTITY columns are read only unless you tell it otherwise. So if we were in tSQL to be able to insert IDENTITY we would turn on IDENTITY_INSERT. Because you are in SSIS you can accomplish the same thing by checking the "keep identity" box.
HOWEVER when ever you get an error like this it is usually a sign that you should NOT be mapping ID to Performance ID. The question you have to ask is the Identity from your source supposed to be the identity of the destination table? Usually not, most of the time it would be another column as a surrogate key. Then you have to understand if it is even possible. because if there is a unique constraint or primary key then the identity cannot repeat which means you have to know that your source's id column will not cause a duplicate primary key violation.
More than likely the actual fix if for you to uncheck ID from the source and ignore the value.
The column PerformanceID (in the target) is almost certainly an identity column and that is why it is not working. You may not want to transfer it (and have SQL Server generate values for PerformanceID or you can check 'Keep Identity.'
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 wanted to modify a column in a sql server 2005 table to IDENTITY(1,1)
Incidentally this table is empty and the column to be changed is a primary key.
This column is also a foreign key for two other tables.
After googling I found that you cannot use Alter table syntax to modify a column and make it an indentity column.
Link #1 : How do I add the identity property to an existing column in SQL Server
Link #2 : Adding an identity to an existing column -SQL Server
I ended up checking the dependent tables (2 of them) removing the foreign keys (generated the script from SSMS) then dropping the main table then re-creating with identity. (could try the rename option here as well)
Then re-created the foreign keys for the earlier dependent two tables.
But all this was manual work, any scripts or SPs out there to make this easier.
Ideally all these steps would be done by such a script/tool/utility:
Check dependent tables keys
Generate Create and drop foreign key scripts for this
Generate create script for the main table
drop the main table (or rename the table if the table has data)
re-create the table with identity column enabled
re-create foreign keys
You can use SSMS to generate a script (Edit a table, save script), but otherwise it's a manual process as you identified.
The SSMS scripts will pick up dependencies etc. For this kind of work, I tend to use SSMS to generate a basic script, pimp it a bit, run it carefully, then use a comparison tool (such as Red Gate compare) to generate a safer version.
Edit: The SSMS error is not an error, it's a safety check that can be switched off
(This is merely a follow-up to gbn's post with more details -- it isn't all that easy to figure this stuff out.)(
It isn't impossible to write a utility to do this, just very complex and very hard. Fortunately, Microsoft has already done it -- its called SSMS (or SMO?). To generate such a script:
In the Object Explorer, drill down to the database and table that you want to modify
Right click and select Design
Make the desired changes to the one table in the design screen. It's reasonably intuitive.
To add/remove the identity property, select the column in the upper pane, and in the lower pane/"Column Properties" tab, expand and configure the settings under "Identity Specification".
To generate a script to implement all your changes, incorporating all the dependent key changes, click on the "Generate Change Script" toolbar button. This is also an option under the "Table Designer" menu.
I also do this to generate scripts (that I later modify--SSMS doesn't always produce the most efficient code.) Once done, you can exit out without saving your changes -- leaving you a DB you can test your new script on.
drop the pk and build the same datatype column
copy the data of the column which you want to set identity to the new column.
drop the old column
reset primary key
ALTER TABLE UserRole
DROP CONSTRAINT PK_XX
ALTER TABLE XX
ADD newX int not null identity(1,1) primary key
update XX set newX = oldX
alter table XX
DROP COLUMN oldX
this is the simplest way to set identity column.
if you don't want to use the long generated script.