Suppose SEQUENCE starts from "1", today it generated some sequences then on next day it should again start from "1".
Is it possible or need to find any workaround ?
Yes: You can schedule a job to recreate the sequence.
Read here: http://docs.oracle.com/cd/E11882_01/server.112/e25494/scheduse002.htm
Depends totally on your database product. Default SQL has no such thing. You need to have some periodic call to the database to reset the value.
You can use a CRON Job which can fire following command(In case you are using MySQL) at noon.
ALTER TABLE table_name AUTO_INCREMENT= 1;
Related
I am using cockroachDB for my app.
One of schemas have incremental id (from 1). I made sequence for that table and use the sequence for primary key.
The problem is that this sequence does not reset unless I drop database and create it.
So my questions are Is it possible to do reset this sequence everytime I run test? or Is it only possible to do it if I drop and create database everytime I run test?
Thank you in advance.
CockroachDB supports the setval() function to reset the value of a sequence.
But also remember that sequences do not guarantee that there will be no gaps (transactions that roll back can leave gaps in the sequence that were never used), so your application should not assume that values start at 1 without skipping anything. If you don't reset the sequence, it's the same as having a very large gap at the beginning of your test suite.
I am pretty sure the only way to accomplish that is to indeed "drop and create database everytime I run test"
Here is a reference - How to rollback, reset, or drop Ecto test database?
In the project I'm working at the Id for certain insert statements is managed by hdbsequences. Now I want to create a sequence for another table that already has existing data in it and I want it to start with the max id value of the data of that table.
I know I could just manually set the "start_with"-Property to it but that is not an option because we need to transport the sequence to another system later where the data in that corresponding table is not the same as on the current system (therefore the ID is different).
I also know of the "reset_by"-Property in which I can select the max value of the table, the problem is that I don't know how to trigger that explicitly.
What I already found out, is that the "reset_by"-Property is called whenever the database is restarted, but unfortunately that is not also not an option because we can't reset the database to not disrupt the other systems.
Thanks in advance for your time and help.
You can do an ALTER SEQUENCE and set the value to be used by the next sequence usage with the option "restart with".
For instance (schema name and sequence name have to be replaced):
alter sequence "<schema name>"."<sequence name>" restart with 100;
The integer value behind the "restart with" option has to be set to the value which has to be used next. So in case your last ID is 100, set it to 101. 101 is the value returned by the next NEXTVAL call on the sequence.
We use a sequence in a Db2 database. Recently, we have migrated the data from an AIX server to a Linux server. During that the latest number of that sequence was not moved to the Linux system. As a consequence, we are seeing duplicates values now.
Here is how we use the sequence:
SELECT NEXTVAL FOR SEQ_YFS_ORDER_NO FROM SYSIBM.SYSDUMMY1
The current value of the sequence on Linux is 100092142. How can I update it to the current value that we have on the AIX system, i.e to (100110960)?
You can modify the sequence using ALTER SEQUENCE. An option offered by ALTER SEQUENCE is to RESTART it with a specific value. Try something like this:
ALTER SEQUENCE SEQ_YFS_ORDER_NO RESTART WITH 100110960
Also note that sequence numbers typically are cached. This may lead to a gap and could have caused the issue during the migration.
Use the below query to fetch next sequence value from DB2 database.
SELECT NEXT VALUE FOR "Sequence_name" FROM SYSIBM.SYSDUMMY1
Work Around
ALTER SEQUENCE SEQ_YFS_ORDER_NO INCREMENT BY (100110960-100092142);
SELECT SEQ_YFS_ORDER_NO FROM dual;
ALTER SEQUENCE SEQ_YFS_ORDER_NO INCREMENT BY 1;
Before backup of your database, you can too create one Stored Procedure to SET "START WITH" with current_value to all your SEQUENCES, so when you will do restore, they will be restored with your desired starts.
Basically I have a table that grows very fast as it registers all user impressions. However most of the data is useless, I only need the latest entry made for each user. (The table is used to authenticate users).
I'm looking to delete the old data, so the table should end up having a stable number of rows around the total number of registered users.
I can use a cron job, then there's the option of simply adding a line at the end of the authentication script that deletes old rows. It would run on every page load.
DELETE WHERE `Date` < NOW() - SOME INTERVAL
Is this efficient, should I use a CRON JOB or what else?
Executing this from the page would add up to the time for the user login.
That is a bad approach. Better use cronjob or some other job scheduling tool like Jenkins
I would say, you could CREATE a temp table to hold your latest records.
And then DROP old table alltogether. Faster :) dropping than deleting.
Rename your temp table to the old one.
So this logic could be in your CRONJOB if you prefer.
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!