Duplicate record no entered in database table - asp.net

I am developing a .ASPX page with following design
Firstname
Lastname
Address
City
Mobile
This is represented to user with labels and textboxes.
When user clicks on Save button, data is saved in SQL Server 2008 Express database table.
Table has following schema
RecordNo-int(PK)
Firstname-nvarchar(50)
Lastname-nvarchar(50)
Address-nvarchar(500)
City-nvarchar(50)
Mobile-nvarchar(12)
At the time of page loading, I also display recordno to user.
This record number is generated based on how many records are there in the table.
I get the number of records and just increment it by 1 and put it against RecordNo.
Now, if this is happening on one PC, it works fine.
First entry will be represented with RecordNo 1
and so on.
But if, there is no record in the table, and the same page is opened by 4 different users at the same time, then all will
be represented with RecordNo 1.
and then, user who first click save button, will be able to save the data perfectly.
But other three users will encounter error, because they are entering information with RecordNo 1, which is already entered.
How do i overcome this?
Each new entry should be given new and unique RecordNo.
Is there any way i can do this?

Why to take headache of showing the number of entries you just set the primary key column to Identity(1,1) which will increment that column value by 1 every time a new row is inserted. This is how 'n' number of user will be able to make entries concurrently.

Set an Identity Cloumn as :
RecordNo int Identity(1,1) Primary Key
In Identity(1,1) first 1 is Starting Value and Other is Increment Value.
Use the code below if you don't want to use Identity:
SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY RecordNo ASC) AS RecordNumber,
FirstName,LastName,Address,City,Mobile from yourTableName) AS RecordNo

Make RecordNo an IDENTITY(1,1) field and forget about all your logic to generate the key. IDENTITY does this for you automatically.
If you require you can call SCOPE_IDENTITY() after the record is inserted to capture the generated value.

Related

Generate incremental unique IDs for users on registration

I have a website wherein I need to users to register themselves by adding their details and submitting. On submitting each user should be allocated incremental unique ids. To test this I had 15 users enter necessary details on the site and then click on register simultaneously, however two set of users got the same ids allocated to them. This is not a problem when all register at different times, then the allocation of ids is unique.
How do I ensure each user gets unique ids even when they register simultaneously.
The "easiest" way to give each user a unique ID would be to either use an IDENTITY column on your user table (if you want the ID to be allocated when the record is successfully written to it), or a SEQUENCE object if you want to get a unique ID before creating the user account in the database.
create table MyUserTable (
UserID int identity(1,1) NOT NULL constraint PK_MyUserTable PRIMARY KEY CLUSTERED
,UserName nvarchar(50)
,Email nvarchar(100);
insert into MyUserTable output inserted.UserId values ('MyUserName', 'me#example.com');
Will write the record to the table and return the ID that was created.
If you want to fetch an ID before writing to the table:
CREATE SEQUENCE UserIds as int start with 1 increment by 1;
create table MyUserTable (
UserID int NOT NULL constraint PK_MyUserTable PRIMARY KEY CLUSTERED
,UserName nvarchar(50)
,Email nvarchar(100);
select next value for UserIds
-- Do whatever you need to do in the application
insert into MyUserTable (UserId,UserName,Email) values (UserIdYouGotEarlier, 'MyUserName','me#example.com');
Understand that with both approaches, you are not guaranteed to have sequential IDs. In the case of a transaction rollback, these will both still auto-increment and those values will be "lost." But you shouldn't be depending upon them being sequential in the first place.
You'll probably want a unique constraint on those username fields too.

How to assign an ID but then delete if not used

I am unsure on how to do this 'best practice' wise.
I have a web application (asp.net VB) that connects to an MS SQL server 2012. Currently when the page loads the app connects to a DB table and gets the last ID and adds 1 to it and displays this to the user. When the user submits the form the new ID is saved to the DB.
The problem being the app may be opened by 2 users at the same time and therefore they will get assigned the same ref number which will cause problems when the data is saved.
How can I assign different numbers to different users if the app is opened at the same time without saving unnecessary data?
You have multiple solutions for this, I'll try to outline a few approaches. (I'll assume that you need to insert things into a DB that I'll call "orders".)
First of all, you can move the ID-generation to the moment when the order is actually inserted, and not at the moment when the user start to enter the data. That way, you do not generate an ID for a user that never completes the form. Also this scenario is easy to accomplish using autoincrementing values in sql server. You can, for example do:
-- create a table with an identity column
create table Orders (
ID int identity(1,1) not null,
Description nvarchar(max) not null
);
-- insert values, without specifying the ID column
insert into Orders (Description) values ()
-- select the row back
-- returns 1, 'My First Order'
select * from Orders;
Another way to do this is to use SQL Server Sequences. These are things that do nothing except generate numbers in a row. They guarantee that the numbers won't be repeated, and always keep count of the current value, i.e.
-- create a sequence
create sequence OrderIdSequence
start with 1
increment by 1;
-- get the next sequence value
select next value for OrderIdSequence

sqlite3 autoincrement - am I missing something?

I want to create unique order numbers for each day. So ideally, in PostgreSQL for instance, I could create a sequence and read it back for these unique numbers, because the readback both gets me the new number and is atomic. Then at close of day, I'd reset the sequence.
In sqlite3, however, I only see an autoincrement for the integer field type. So say I set up a table with an autoincrement field, and insert a record to get the new number (seems like an awfully inefficient way to do it, but anyway...) When I go to read the max back, who is to say that another task hasn't gone in there and inserted ANOTHER record, thereby causing me to read back a miss, with my number one too far advanced (and a duplicate of what the other task reads back.)
Conceptually, I require:
fast lock with wait for other tasks
increment number
retrieve number
unlock
...I just don't see how to do that with sqlite3. Can anyone enlighten me?
In SQLite, autoincrementing fields are intended to be used as actual primary keys for their records.
You should just it as the ID for your orders table.
If you really want to have an atomic counter independent of corresponding table records, use a table with a single record.
ACID is ensured with transactions:
BEGIN;
SELECT number FROM MyTable;
UPDATE MyTable SET number = ? + 1;
COMMIT;
ok, looks like sqlite either doesn't have what I need, or I am missing it. Here's what I came up with:
declare zorder as integer primary key autoincrement, zuid integer in orders table
this means every new row gets an ascending number, starting with 1
generate a random number:
rnd = int(random.random() * 1000000) # unseeded python uses system time
create new order (just the SQL for simplicity):
'INSERT INTO orders (zuid) VALUES ('+str(rnd)+')'
find that exact order number using the random number:
'SELECT zorder FROM orders WHERE zuid = '+str(rnd)
pack away that number as the new order number (newordernum)
clobber the random number to reduce collision risks
'UPDATE orders SET zuid = 0 WHERE zorder = '+str(newordernum)
...and now I have a unique new order, I know what the correct order number is, the risk of a read collision is reduced to negligible, and I can prepare that order without concern that I'm trampling on another newly created order.
Just goes to show you why DB authors implement sequences, lol.

Web Form Next Number Generation Scenario

I have a web form with several fields first field is Employee Number which is having "EMP - 0001" Format.i'm generating next Employee number by considering the last Emp Number added and converting the latter part to integer and add one
ex: split EMP - 0001 -> get 0001 -> convert it to integer -> add one -> generate next no as EMP - 0002
Next Employee Number should be visible to the user.my issue is when there are multiple users using the system.imagine that one user opens the web Form and doesn't save the record.his Employee Number is EMP - 0002.another user opens the web form he also sees the EMP no as 0002 because last record is not saved yet.2nd user saves the records he gets the Number 0002.1st user then saves the record.so at last i've got duplicate EMP Numbers in my database.what kind of scenario should i follow to over come this situation
The only way to accurately predict their ID is to put in a blank record, get the ID used, then when they enter the form, update the record with their information. However, if they quit the form, you're left with a blank record.
Insert the record on the DB and get the ID it returns. You won't have concurrency issues there if you're opening and disclosing your connection correctly.
Your current approach is prone to concurrency issues as you pointed out & I will not recommend it you. You have the following options.
Use an Identity column in your database table as a serial column (The database automatically increments the identity column on every insert row operation- you don't have to specify it through code)SQL Server Identity
Use a database sequence (Depeding on your database version & its support - A database sequence returns a unique integer value - this can also be cached, presented on form once the form loads - once generated, same sequence is never generated again)
Use a database trigger to automatically update the Id column on every row insert
Depeding on your requirement, you can pick one option.
After saving the record you can give the user message tah record is saved and your Employee numnber is "EMP - 0002".

The ids of a table in my sqlite database have been reset

I have an iPhone app and one of my users found a really strange problem with my application. I can't reproduce the problem and I can't figure out why it's happening. Maybe you can?
In Sqlite I have a table with about 1000 rows, each with a unique id. But for some reason the id of that table has restarted, before it was around 1000 but now it's restarted from 80 something. So everytime the user inserts a new row the new assigned id starts around 80 something and I get two duplicates ids that should be unique and yeah you can understand the problem. I have looked at all queries that does anything to that table and none of them could have done this. I always relay on the built in mechanism where the ids are assigned automatically.
Have you seen anything like this?
The schema of the table looks like this:
CREATE TABLE mytable(
id INTEGER PRIMARY KEY
);
As you can see I don't use AUTOINCREMENT. But from what I understand even if the user deletes a row with id 80, it is ok to give a new inserted row id 80 but not like it works now where the database just keeps incrementing the ids even if I have already have rows with the same id. Shouldn't it work like this:
HIGHEST ROWID IS 1000, ALL IDS FROM 0-1000 ARE TAKEN
USER DELETES ROW WITH ID 80
INSERT A NEW ROW
THE ID OF THE INSERTED ROW MIGHT NOW BE 80
SETS THE ID OF THE INSERTED ROW TO 80
INSERT A NEW ROW
THE ID OF THE INSERTED ROW CAN NOT BE 81 AS THIS IS ALREADY TAKEN
SETS THE ID OF THE INSERTED ROW TO 1001
Isn't that how it should work?
Did you declare your id column as a(n autoincrementing) primary key?
CREATE TABLE mytable(
id INTEGER PRIMARY KEY AUTOINCREMENT
);
By adding the autoincrement keyword you ensure that all keys generated will be unique over the lifetime of your table. By omitting it, the keys will still be unique, but it may generate keys that have already been used by other, deleted entries. Note that using autoincrement can cause problems, so read up on it before you add it.
Edit This is a bit of a long-shot, but sqlite only supports one primary key per table. If you have more than one primary key declared, you need to declare all but the one you actually want to use as a primary key as "unique". Hence
CREATE TABLE mytable(
id INTEGER PRIMARY KEY,
otherId INTEGER UNIQUE
);
Hard to say without the code and schema, but my instinct is that this unique ID is not defined as either unique nor primary key, which they should.
How do you make sure (in theory) id's are unique? What is your insert query like?

Resources