Implement an unique key constraint in ADF BC - oracle-adf

I have a table for the users to add records. In my requirement, for one of the column, I should not allow the user to enter duplicate value.
This is not primary key field. How to validate the column for duplicate on click of save button and it should show an error message.
Example
If i have a countries table shown to the user to add countries and it consists of columns
country id (not primary key)
country name
I want the country id to be unique. When the user enters a duplicate value it should display an error message on click of save button

You can create an Alternate Key Constraint on the EO and then use the UniqueKey Validation to validate the key value at commit time.

Related

Create Primary key in sql server

I have one table in sql server having duplicate ID,but I can not delete those duplicate records .Now the requirement is to create the primary key on that column which is having duplicate data. Is there any way to create the primary key without changing the data.
No, there is no way to a add a PRIMARY KEY constraint to a column that already has duplicate values.
Creating and Modifying PRIMARY KEY Constraints:
When a PRIMARY KEY constraint is added to an existing column or
columns in the table, the Database Engine examines the existing column
data and metadata to make sure that the following rules for primary
keys:
The columns cannot allow for null values.
There can be no duplicate values.
If a PRIMARY KEY constraint is added to a
column that has duplicate values or allows for null values, the
Database Engine returns an error and does not add the constraint.
In case ID column is incremental, then a possible workaround is to add a unique filtered index:
CREATE UNIQUE INDEX AK_MyUniqueIndex ON dbo.MyTable (ID)
WHERE ID > ... max value of existing ID here
This way, uniqueness will be applied only to newly added records.
I know this is old, but, had this idea that I wanted to share:
Step 1. Add a non-nullable int column with a default value that can
be 0
Optional step. Update that column to a 1, so you are able to
identify this existing records afterwards.
Step 2. Update column in all existing rows where there are duplicates with a standard rownumber() using a combination of unique columns or all columns.
Step 3. Define primary key with your ID column first (So, it is
indexed first), then add Step 1 column.
And you are done and with a special column that can helps identify the duplicates easily and the new records which will be all marked as 0, but the best practice would be to add a character or number to all Ids if possible and standardize (This approach helps to do that afterwards), or use something like by year sequence, etc.

unique entity in a database

How can we make a constraint on the database, so that only one entity fits in a desired position?
For example, we want to have a president for the Country database.
How can we define the "is-president" attributes so that only one entry can have the "true" value.
You can do it when inserting the data to your table. If you want to add a president, first check whether there is a president or not.
You're better off modelling this in a different way - for example having a Countries table, a People table, and then a Presidents table which has a foreign key to the Countries table, and a foreign key to the People table.
You can then add a unique constraint on the composite value of both foreign keys to ensure only 1 person exists per country within the Presidents table.

Database column naming for foreign key

should I signal the foreign key in a database column name?
FKOrder vs. FK_Order vs. Order
The short answer is no - don't put "FK" in column names of foreign key columns. You can still signal the intent of the column though, here's how I do it:
Naming foreign key columns
It depends on your naming convention for the target of the FK. If you have Id, then I'd prepend the table name when creating FK columns.
Example 1:
For table User with PK Id and table Workitem with user ID FK, I'd call the column Workitem.UserId.
If there were more than one FK between the same tables, I'd make this clear in the column name:
Example 2:
For table User with PK Id and table Workitem with "assigned to user ID" and "created by user ID" FKs, I'd call the columns Workitem.CreatedByUserId and Workitem.AssignedToUserId.
If your naming convention for PKs is more like UserId, then you'd factor that into the above examples so as not to end up with UserUserId.
Naming foreign key constraints
This is mine:
FK_childtablename_[differentiator]parenttablename
The differentiator is used when there is more than one FK between the same two tables (e.g. CreatedByUserId and AssignedToUserId). Often I use the child table's column name for this.
Example 1:
Given tables: Workitem and User
Where User has CreatedByUserId and AssignedToUserId
Foreign key names are FK_Workitem_User_CreatedByUser and FK_Workitem_AssignedToUser
I use double-underscores if tables/columns have underscores in the name:
Example 2:
Given tables: work_item and user
Where user has created_by_user_id and assigned_to_user_id
Foreign key names are FK_work_item__created_by_user and FK_work_item__assigned_to_user
Is usual to name the foreign key fields with an ID (IDORDER, IDPERSON, ...), if you have a table called PERSONS and another CITIES, if one person is in certain city, CITIES has an IDCITY field (K), PERSONS has a IDPERSON (K), and other field IDCITY (FK).
Hope this answers your question. I mean, a foreign key is only foreign when it's in other table, but not in theirs. But it's a good practice to name always the same to the same fields, even if they are in other tables, as a foreign key.
You shouldn't.
If a column becomes a foreign key later, you will have to change the column name, breaking all the scripts that are using it.
If there are multiple foreign keys, you don't know which column belongs to which key, so the only information you gain is that the column is a foreign key, but you already know it by looking at the keys.
Usually I name the foreign key column the same as the primary key, so I know immediately where the key maps.
I normally use the same name as the referenced column in the table holding the FK.
Only if this is potentially confusing (or a column with this name already exists, say id), would I be more explicit. In such a case, adding the entity type name before the rest - say ProductId.
My style is slightly different:
fk_table_column
eg: fk_user_id that is foreign key to User table on id column. I do not use any capital latter.

How can I change a primary key value in one-one relationship?

Hi
I'm using entity framework 4 as business layer.
I've two table in one-one relationship:
Users <---> Employees
Employees table have the same primary key as Users table, so when I add record to Users i have to add one to Employees with the same PK value...and that throws an exception.
Actually I'm doing this using entity framework :
// after adding new Users entity, I add new Employee item to it
newUserEntity.Employee = newEmployeeEntity;
What should I do to be able to insert the PK manually ?
Thanks in advance
There are a number of ways to fix this.
The first one is why do you have two tables. Could you instead have a single table but have a User and an Employee view of that table.
The second is that if you have two tables, why do both of them have an auto generated primary key. You could generate the key in the program (or get it from a key table) and then just insert the key values in the tables.

How I can make Recycle Bin for Database Application?

I have database application, I want to allow the user to restore the deleted records from the database, like in windows we have Recycle bin for files I want to do the same thing but for database records, Assume that I have a lot of related tables that have a lot of fields.
Edit:
let's say that I have the following structures:
Reports table
RepName primary key
ReportData
Users table
ID primary key
Name
UserReports table
RepName primary key
UserID primary key
IsDeleted
now if I put isdeleted field in UserReports table, the user can't add same record again if it marked as deleted, because the record is already and this will make duplication.
Note: I always use surrogate primary key.
Add a timestamp 'deleted_at' column. When user deletes entry put there current time. Make this key part of your constrain.
In every query remember to search only for records that have null in deleted_at field.
Some frameworks (like ActiveRecord) make it trivial to do.

Resources