I pushed a Ruby on Rails test application up to Heroku and, after running the command heroku run rake db:migrate, received a notification that says:
NOTICE: CREATE TABLE will create implicit sequence "microposts_id_seq" for serial column "microposts.id"
What is an implicit sequence? And, in this case, is a "serial column" another way to refer to a primary key?
Your table contains a column which is defined as serial which is just a shorthand for an integer column which default value is taken from a sequence. In order to do that, PostgreSQL automatically creates a sequence that is bound to that column. The message merely tells you that such a sequence was created.
If you didn't explicitely define a serial column, you probably defined it as "autoincremen" or whatever the Ruby term for that is.
For more details please read the manual: http://www.postgresql.org/docs/current/static/datatype-numeric.html#DATATYPE-SERIAL
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'm using code first migrations with entity framework. I've got a column that was created a few migrations ago called Amount which is marked as 'required', that stores an integer value. I've now been told, this needs to be a decimal. When I change the datatype in my context and run 'Add-Migration, it creates the migration file as I expect.
When I run Update-Database, it gives me the following error
The object 'DF_Products_ProductsTrack__522F1F86' is dependent on
column 'Amount'. ALTER TABLE ALTER COLUMN Amount failed because one or
more objects access this column.
I've managed to write some custom SQL to do this manually:
ALTER TABLE Products
DROP CONSTRAINT [DF__Products__ProductsTrack__522F1F86]
GO
ALTER COLUMN Amount decimal(18,2)
However, this is no good as I need the datatype changed as part of my migrations. I am write in assuming the dependency is because of the 'Required' attribute that was initially assigned to it? How do I change the type using 'normal' migration techniques?
I created a User defined table type named tvp_Shipment with two columns (id and name) . generated a snapshot and the User defined table type was properly propagated to all the subscribers.
I was using this tvp in a stored procedure and everything worked fine.
Then I wanted to add one more column created_date to this table valued parameter.I dropped the stored procedure (from replication too) and also i dropped and recreated the User defined table type with 3 columns and then recreated the stored procedure and enabled it for publication
When I generate a new snapshot, the changes in user defined table type are not propagated to the subscriber. The newly added column was not added to the subscription.
the Error messages:
The schema script 'usp_InsertAirSa95c0e23_218.sch' could not be propagated to the subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)
Get help: http://help/MSSQL_REPL-2147201001
Invalid column name 'created_date'. (Source: MSSQLServer, Error number: 207)
Get help: http://help/207
On the publication, is the replicate_ddl option set to true? Also, what's the value for the pre_cmd value for the article in question? If neither of those point you in the right direction, take a look at the file that it says is failing. It should be a human-readable T-SQL file that's located at the distributor in the snapshot folder. If the error isn't obvious, you can try running it at the subscriber and see what it gives you. My guess is that it didn't replicate the column change, but you put an index on it which references that column. But that's just a guess.
I recently created a SQL dump of a database behind a Django project, and after cleaning the SQL up a little bit was able to restore the DB and all of the data. The problem was the sequences were all mucked up. I tried adding a new user and generated the Python error IntegrityError: duplicate key violates unique constraint.
Naturally I figured my SQL dump didn't restart the sequence. But it did:
DROP SEQUENCE "auth_user_id_seq" CASCADE;
CREATE SEQUENCE "auth_user_id_seq" INCREMENT 1 START 446 MAXVALUE 9223372036854775807 MINVALUE 1 CACHE 1;
ALTER TABLE "auth_user_id_seq" OWNER TO "db_user";
I figured out that a repeated attempt at creating a user (or any new row in any table with existing data and such a sequence) allowed for successful object/row creation. That solved the pressing problem.
But given that the last user ID in that table was 446 - the same start value in the sequence creation above - it looks like Postgresql was simply trying to start creating rows with that key.
Does the SQL dump provide the wrong start key by 1? Or should I invoke some other command to start sequences after the given start ID? Keenly curious.
The dump is fine, no problem. If your code (or default value for the column) uses nextval() to get the next value from the sequence, everything will be fine as well. Check your code and see what it does, what SQL is executed. With this information you can see why things are going wrong.
Good luck!
I've just wasted the past two hours of my life trying to create a table with an auto incrementing primary key bases on this tutorial, The tutorial is great the issue I've been encountering is that the Create Target fails if I have a column which is a timestamp and a table that is called timestamp in the same table...
Why doesn't oracle flag this as being an issue when I create the table?
Here is the Sequence of commands I enter:
Creating the Table:
CREATE TABLE myTable
(id NUMBER PRIMARY KEY,
field1 TIMESTAMP(6),
timeStamp NUMBER,
);
Creating the Sequence:
CREATE SEQUENCE test_sequence
START WITH 1
INCREMENT BY 1;
Creating the trigger:
CREATE OR REPLACE TRIGGER test_trigger
BEFORE INSERT
ON myTable
REFERENCING NEW AS NEW
FOR EACH ROW
BEGIN
SELECT test_sequence.nextval INTO :NEW.ID FROM dual;
END;
/
Here is the error message I get:
ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed
Any combination that does not have the two lines with a the word "timestamp" in them works fine. I would have thought the syntax would be enough to differentiate between the keyword and a column name.
As I've said I don't understand why the table is created fine but oracle falls over when I try to create the trigger...
CLARIFICATION
I know that the issue is that there is a column called timestamp which may or may not be a keyword. MY issue is why it barfed when I tried to create a trigger and not when I created the table, I would have at least expected a warning.
That said having used Oracle for a few hours, it seems a lot less verbose in it's error reporting, Maybe just because I'm using the express version though.
If this is a bug in Oracle how would one who doesn't have a support contract go about reporting it? I'm just playing around with the express version because I have to migrate some code from MySQL to Oracle.
There is a note on metalink about this (227615.1) extract below:
# symptom: Creating Trigger fails
# symptom: Compiling a procedure fails
# symptom: ORA-06552: PL/SQL: %s
# symptom: ORA-06553: PLS-%s: %s
# symptom: PLS-320: the declaration of the type of this expression is incomplete or malformed
# cause: One of the tables being references was created with a column name that is one of the datatypes (reserved key word). Even though the field is not referenced in the PL/SQL SQL statements, this error will still be produced.
fix:
Workaround:
1. Rename the column to a non-reserved word.
2. Create a view and alias the column to a different name.
TIMESTAMP is not listed in the Oracle docs as a reserved word (which is surprising).
It is listed in the V$RESERVED_WORDS data dictionary view, but its RESERVED flag is set to 'N'.
It might be a bug in the trigger processing. I would say this is a good one for Oracle support.
You've hinted at the answer yourself. You're using timestamp as a column name but it's also a keyword. Change the column name to something else (eg xtimestamp) and the trigger compiles.
Well, I'm not totally sure about it, but I think this happens because the SQL code used to manipulate and access database objects is interpreted by some interpreter different form the one used to interpret PL/SQL code.
Have in mind that SQL an PL/SQL are different things, and so they are processed differently. So, I think there is some error in one interpreter, just not sure which one is.
Instead of having Oracle maintain a view, use EXECUTE IMMEDIATE (i.e. if 'Rename the column to a non-reserved word' is not an option.
You can execute via EXECUTE IMMEDIATE. IT's not better way but work's and avoid column rename.
In my case rename column will be a caotic way