Get next value of AUTO INCREMENT - sybase-ase

How do i determine what the next value is of the Primary Key Auto increment?
I have been looking in the system databases but i couldnt find any answers.

I am guessing you mean "the next value to be assigned to an identity column", and your identity column also happens to be used as a primary key. Otherwise, there is no concept in Sybase ASE that would qualify as "Primary Key Auto increment".
Assuming the above, you can get the next value to be assigned by using the function next_identity('table_name'). Note that the result is in varchar format so you may need to convert it back to a number.

Related

Is Access's AutoNumber (Increment) guaranteed to increment?

For a particular table, I have my ID field set to AutoNumber (Increment). If I add 5 rows to this table in quick succession, is each guaranteed to have a larger ID than the last? For instance, does autonumbering ever restart from 1 if some earlier values have been deleted?
The only time I have ever had trouble with Access autonumbers is when, in error, I set the value of an autonumber key field to a number lower than the current maximum using an append query. Gaps had been created in the numbering by record deletions. Access allows you to force a value into an autonumber field, and sometimes (not always, and I don't know why) the autonumbering gets reset to the lower number. Eventually, as records were added, I ran into 'duplicate key' errors. Other than this, I've never had trouble in many years.
There are a couple of answers to this question which talk about an increment value. As far as I know, an Access autonumber field can only be set to 'Increment' (by 1) or 'Random', and there is no way of setting a numeric increment other than 1. If I am wrong about this, please enlighten me.
Sadly, even Microsoft's applications are not infallible. But that's the way it's intended to work, and I've not seen it fail; nor heard of it fail short of intential or accidental subversion.
Just don't expect it to have a row for every integer value, though. In addition to deleted rows, it will use up numbers for append operations that fail.
The statement "If some records are deleted AND the database is compacted the next identity is reset to the lowest used number + 1" is incorrect. This happened in Jet 3.5 used in Access 97 but not Jet 4.0 used in Access 2000.
David W. Fenton wrote: "The Jet Autonumber field is not an identity field. It is only a long integer field with a special default value. That default value can be INCREMENT or RANDOM, but as it is only a default value, you can append any long integer value to the field as long as it doesn't violate the index."
This is a bit confused. ACE/Jet SQL syntax has an IDENTITY keyword (COUNTER, AUTOINCREMENT) but no AUTONUMBER keyword. Clearly an ACE/Jet IDENTITY is an IDENTITY!
But what I want to address here (too long for a comment) is the misstatement about it being "only a long integer field with a special default value".
Consider this ACE/Jet SQL DDL (ANSI-92 Query Mode syntax):
CREATE TABLE Test2_IDENTITY
(
ID_identity_1 IDENTITY NOT NULL,
ID_identity_2 IDENTITY NOT NULL,
data_column INTEGER
);
When executed, it fails with the message, "Resultant table not allowed to have more than one AutoNumber field". So clearly there is something other than just a "special default value" going on here.
The IDENTITY keyword is creates an autonumber (for want of a better term) with an incrementing algorithm to generate values. IDENTITY cannot be used to create an autonumber with a random algorithm or a GUID (replication ID) flavour of autonumber. For these other cases you do indeed need to use a "special default value" e.g.
CREATE TABLE TestAutonumbers
(
ID_identity IDENTITY NOT NULL,
ID_random INTEGER DEFAULT GenUniqueID() NOT NULL,
ID_guid UNIQUEIDENTIFIER DEFAULT GenGUID() NOT NULL,
data_col INTEGER
);
If you use a technology such as ADOX to examine this table's properties (information schema) you'll find that only the column created with the IDENTITY keyword has the Autoincrement property set to true, and this column's COLUMN_HASDEFAULT is false and COLUMN_DEFAULT is null. So if an IDENTITY column does have a "special default value" then the engine isn't telling.
Unlike IDENTITY, with these other flavours of autonumber there is no explicit one per table restriction e.g. this works fine:
CREATE TABLE Test2_Autonumbers
(
ID_random_1 INTEGER DEFAULT GenUniqueID() NOT NULL,
ID_random_2 INTEGER DEFAULT GenUniqueID() NOT NULL,
ID_guid_1 UNIQUEIDENTIFIER DEFAULT GenGUID() NOT NULL,
ID_guid_2 UNIQUEIDENTIFIER DEFAULT GenGUID() NOT NULL,
data_col INTEGER
);
Something I do not know is whether there exists a "special default value" equivalent to GenUniqueID() and GenGUID() to create an auto-increment column using DEFAULT and without using the IDENTITY keyword (or its synonyms). If anyone knows one way or the other, please let me know.
BTW the abovementioned error message suggests I was wrong about 'Autonumber' being an Access term. Seems at the ACE/Jet engine level 'Autonumber' is a non-keyword synonym for IDENTITY (i.e. auto-increment flavour autonumber) but not a synonym for other flavours of autonumber.
I have a table that was formerly used in a replicated database. Some of the autonumbers are negative, and some are very large. This is normal for a replicated table, so you cannot be certain that an autonumber will be larger than the previous number, it could be negative.
The Jet Autonumber field is not an identity field. It is only a long integer field with a special default value. That default value can be INCREMENT or RANDOM, but as it is only a default value, you can append any long integer value to the field as long as it doesn't violate the index.
An incrementing Autonumber will never revert to 1 except if you've deleted all records and compacted, or in the event of a corrupt seed value. The latter happened frequently in the early versions of Jet 4 (before service pack 6), where the seed value would get reset, and this would lead to all sorts of problems, including corrupted PK indexes. Fortunately, that eventually got fixed, and because Jet is a Windows component, hardly any computer out there is going to have anything less than Jet 4 service pack 8.
As onedaywhen said, you can get negative values if the incrementing Autonumber exceeds the maximum positive value for long integer, but this would indicate to me that you probably have enough records in your table that you need a different database engine, or you're improperly treating your table as a temp table (i.e., appending and deleting large numbers of records).
As others have also said, uniqueness is not controlled by the Autonumber data type, but by the index. If you created a non-unique index, you could append duplicate values. I can't imagine why you'd want an Autonumber field with duplicate values, but the point is that you can do it if you don't add a unique index. Since most Autonumber fields are used as surrogate primary key, they will have the unique PK index, and the data table will be written in PK order (clustered). In regard to uniqueness, if you are using an Autonumber as a surrogate PK and you have any natural keys in the table that should be unique (and can be unique, i.e., no Nulls allowed), you should also have a unique index on the natural key field(s) (a single field or a compound index).
First, your IDENTITY (Autonumber in Access) column must be INTEGER (Long Integer in Access) as opposed to UNIQUEIDENTIFIER (Replication ID in Access), must use the increment algorithm as opposed to the random algorithm for generating new values and assuming your seed and increment values respectively are both the default value 1, then if you delete all the rows in the table and compact the database then the IDENITTY column should be reseeded at 1. If it doesn't then you may need to install a Jet service pack (http://support.microsoft.com/kb/287756).
Note that when the maximum positive value for INTEGER (Long Integer in Access) would be exceeded by the next auto-generated value then it will 'wrap' into the negative INTEGER range and will continue to cycle through the positive and negative ranges, generating duplicate values where necessary (unless the column is additionally covered by a unique constraint). Indeed, if the increment value is large enough you can guarantee that the values will alternate between being greater than and less than the previous auto-generated value e.g. (ACE/Jet ANSI-92 Query Mode syntax):
CREATE TABLE Test
(
ID INTEGER IDENTITY (0, 2147483647),
data_col INTEGER NOT NULL UNIQUE
)
;
INSERT INTO Test (data_col) VALUES (1)
;
INSERT INTO Test (data_col) VALUES (2)
;
INSERT INTO Test (data_col) VALUES (3)
;
INSERT INTO Test (data_col) VALUES (4)
;
INSERT INTO Test (data_col) VALUES (5)
;
INSERT INTO Test (data_col) VALUES (6)
;
INSERT INTO Test (data_col) VALUES (7)
;
INSERT INTO Test (data_col) VALUES (8)
;
The auto-generated values are 0, 2147483647, -2, 2147483645, -4, 2147483643, -6, 2147483641, etc.
My answer is 3 strings of VBA code!
Set db = CurrentDb
Set tbl = db.TableDefs("your_tbl")
Set current_index = tbl.Indexes.Item("PrimaryKey").DistinctCount
If some records are deleted AND the database is compacted the next identity is reset to the lowest used number + 1 - if the table is emptied the next identity is set back to 1 after the compact.

IndexedDb. Insert items on empty (previously deleted)

I have a store with keyPath and autoincrement=true.
I have 100 items, I delete the 50'th.
I cannot get to insert a new 50's....
The result is always the same: 100 items with the 50's occuping the keypath 101....
Is there any way to insert that '50' item ?
Thanks
Not automatically. The key for a new record always increases. You'd have to manually keep track of which keys are deleted and manually set that key for a new record. See the spec for excruciating details, but this bit is relevant:
A practical result of this is that the first key generated for an object store is always 1 (unless a higher numeric key is inserted first) and the key generated for an object store is always a positive integer higher than the highest numeric key in the store. The same key is never generated twice for the same object store unless a transaction is rolled back.

Mysql id auto increment not null sift up when row deletes [duplicate]

This question already has an answer here:
Auto Increment after delete in MySQL
16 answers
I am not getting anywhere on Internet. I want to shift row up (change id of row) upon row deletion. Like:
id value
1 edt55tgge
2 edgg545re
3 gt5edbeg4
4 e98i7thde
5 455t44ede
When I delete row 2 and 4, the table should become
id value
1 edt55tgge
2 gt5edbeg4
3 455t44ede
I am using id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, where this becomes impossible.
Please help.
This isn't the way auto increment columns are meant to work, you really are best to leave it to sort itself out.
Add another INT column, called something like my_id and use that for what you want to do.
EDIT: Also you can't always guarantee that the auto increment value will be sequential, some cloud providers have their auto increment keys jump in 10's or 20's because of the mirroring and clustering etc... Best not to mess with them.
You shouldn't amend auto increment. It's part of the database design. You should use another column name as the identifier. need to add another column.
if you using this in php then better to do some code functionality for the column (not auto_incremented).
Thanks

How to create unique index in Access w/ integer fields that may be null?

I'm trying to create a unique multi-column index on a table in Access. Several of the fields I'll be using in the index are long integers. These fields may be blank in some records. I know that I can't allow actual NULLs because then I can't have unique records, e.g. if I try to build the table as follows:
Field1 (text),Field2 (integer),Field3 (text)
1:"a",56,"c"
2:"x",NULL,"f"
3:"x",NULL,"f"
then row 3 will be allowed (which I don't want) because the NULLs aren't really "equal" to each other.
I saw a solution where they set the following in Design View:
"Required"="Yes"
"Allow Zero Length"="yes"
"Default value"=""
But that won't help here because integers can't be set to "".
So, any ideas on creating a unique index under these circumstances?
I'm goin on general DB theory, but Acess could break the mold. Theory makes NULL fail to do as you wish because DBs take null to essentially mean "give up on evaluating". This leaves you to set a default value, like 0, -1 or minimum int for example, but that leaves you with fake, meaningless data--a very bad thing.
Can you add a surrogate field (say of string type) that is populated with the string representation of your integer? Not sure about Access, but triggers or calculated columns are two general DBMS options for doing this.

Generating a unique ID

I was looking into functions that generate unique IDs - my specific requirement is that the unique ID would need to be 8 digits only.
Anyway I've just realised we can set an ID auto increment field to start from any number. So suppose I have it start from 11111111 - am I right in thinking that all new records will increment from this value? If so then I have my unique 8 digit ID and no need to use a function for this.
And also if a record is deleted then will a new record re-use that deleted ID?
1) Autoincrement-Values are not reused
2) Yes, by setting the autoincrement counter to an 8-digit number (e.g. 10000000), you can achieve this! (Table option "AUTO_INCREMENT = N")
That is correct. If your auto-number columns start at 11111111, then your next row will have the number 11111112.
When a record is deleted, its auto-number is not reused.
Edit: Regarding maximum values, that is dependent on the column type you have chosen. From the MySQL documentation:
Use a large enough integer data type for the AUTO_INCREMENT column to hold the maximum sequence value you will need. When the column reaches the upper limit of the data type, the next attempt to generate a sequence number fails. For example, if you use TINYINT, the maximum permissible sequence number is 127. For TINYINT UNSIGNED, the maximum is 255.
You could use an INT and go up to 4294967295, or BIGINT and go up to 18446744073709551615. See http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

Resources