The diagram has over 40 tables, most of them have a primary key defined.
For some reason there is this one table, which has a primary key defined, but that's being ignored when I export the model to a DDL script.
This is the "offending" key (even though it's checked it is nowhere to be found on the generated DDL script):
Has anybody had the same problem? Any ideas on how to solve it?
[EDIT] This is where the key is defined:
And this is the DDL preview (yes, the primary key shows up there):
This is what happens if I try to generate the DDL for just that table (primary key still not generated):
I was finally able to identify and reproduce the problem.
It was a simple conflict of constraints.
Table MIEMBROS had a mandatory 1 to n relationship (foreign key) from another table on its primary key column and vice-versa (there was a foreign key on MIEMBROS against the other table's primary key).
This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table.
Anyway I realized that one of the relationships was 0 to n so I simply unchecked the "mandatory" checkbox on the foreign key definition and everything went fine.
So, in a nutshell: The Data Modeler "fails" silently if you are defining a mutual relationship (two foreign keys, one on each table against the other table) on non nullable unique columns, by not generating the primary key of one of the tables.
Such an odd behavior, if you ask me!
"This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table."
Actually, if you have deferred constraints, this is not impossible. The constraints can be enforced, for example, at commit time rather than immediately at insert time.
From the Data Modeler menu under File, I used Export -> DDL File. The keys appeared in the DDL, then when I went back to the diagram and did DDL Preview, it showed all the missing stuff.
Related
I am using talend for ETL I don't have enough experience in this, I am having two tables for example- account and account_roles account table is having id, name, password etc fields and account_roles table is having account_id which is f.k to account table's pk. and one more field.
Both the fields in account_roles are having duplicates, I want to save account_roles in destination with update and insert logic using talend.
But I am getting error as I don't have any table that can be treated as primary key in the account_roles table, so talend can't update or insert it.
How I deal with this situation I tried tDBOutput advance option use_field_option but still it requires unique entries.
Is there any possible solution to this issue, I also want to know if I can make table Foreign key in the account_roles table will it work then? If yes then How to make F.k in talend OPen studio is my second question.
Attaching Snapshots of my tables and tMap below -
I want to know the way I can put my tables into database if I don't have any primary key! Kindly help me.
First question
I think you should place the primary key in the physical account_roles table. Talend will use the key indication of the dbOutput component, and the physical key of the table.
In order to delete duplicates rows, you can also use a tUniqRow before the dbOutput: The key you indicate in the UniqRow is not directly linked to the database; this is only the key on which tUniqRow will be based.
Second question
It's not possible to delegate the f.k. verification to Talend. But you can do this verification in your database by placing foreign keys in your table. If an id is not present in the reference table, the database returns an error that is returned by Talend.
I wanted to understand that if we drop a PRIMARY KEY using online then what will be the situation for ongoing transactions. Will the maintain data integrity? ideally not cause we have dropped PK. But what could be the real scenario from dropping constraints using online or how we can prevent data conflicts while doing so.
In Oracle, you can keep index but drop Primary Key. In this way you can prevent data conflicts.
ALTER TABLE TBL DROP PRIMARY KEY KEEP INDEX
after that you can add new primary key or unique constraint (whatever it is) and drop former unique constraint
I have a PDM in Power Designer that I need to implement on my Oracle database.
I want to test two cases, one with the constraints like Primary Key & Foreign Key and one without those constraints.
I don't know how to do the 2nd case, do I need to use Unique Indexes ? How can it work like a fk in my diagram ? How can avoid to implement the foreign keys but still have them in my diagram ? Is there an option to not enforce the foreign key in my database ?
I can't find any or proper way to deal with the 2nd case
Thanks for your help
#pascal's comment do the trick :
On in Database > Generate Database, Options tab, in All Objects >
Table & Column > Foreign key, you have a Create foreign key checkbox
I'm using Pentaho for my ETL process and I'm having an issue inserting a flat file into a table with a primary key and foreign key relationship. The transformation is fairly straight forward having a Microsoft Excel Input, Add Constants, and Table Output transformations. The error I'm getting is "The INSERT statement conflicted with the FOREIGN KEY constraint". I believe that you can use a insert/update output transformation but the performance is awful. Please provide suggestions on how to resolve.
primary_key = Staff_key
foreign_key = Staff_profil_key
The table output transformation has an option to ignore insert errors. You can check this option to ignore the constraint. This option can not be used in conjunction with the batch update thus affecting performance.
I have 2 tables in my database that I'm trying to create Linq2Sql entities for. There's more to them than this, but this is essentially what they come down to:
Rooms UserActivity
-------- --------
RoomID ActivityID
RoomID (foreign key on Rooms.RoomID)
The UserActivity table is essentially just a log for actions a user performs against the Rooms table.
Since the UserActivity table is only used for logging actions taken, it didn't make a lot of sense (to me at least) to create a primary key for the table originally, until the Linq2Sql mapper refused to make UserActivity a part of the Room entity in my Linq entities. When I set up the entities in the Visual Studio designer, I got these 2 warnings:
Warning 1 DBML1062: The Type attribute 'UserActivity' of the Association element 'Room_UserActivity' of the Type element 'Room' does not have a primary key. No code will be generated for the association.
Warning 2 DBML1011: The Type element 'UserActivity' contains the Association element 'Room_UserActivity' but does not have a primary key. No code will be generated for the association.
These warnings led me to create the ActivityID column in my table as displayed above.
What I'd like to know is if there is any way to allow Linq2Sql to create relationships between my entities without having a primary key in both tables. If I don't have the primary key in the UserActivity table, the entities can still be created, but the relationships aren't generated.
Is is it possible to do this, or should I try to make sure my tables always have a primary key in them as a general good practice?
Any table that stores real data in your app should always have a primary key - most cases, in SQL Server environments, a INT IDENTITY(1,1) will be just fine. You don't have to keep track of those, no bookkeeping necessary etc. It doesn't cost you much, totally easy to do - I don't see any reason why not have a primary key, even on your UserActivity table.
ALTER TABLE UserActivity
ADD UserActivityID INT IDENTITY(1,1)
CONSTRAINT PK_UserActivity PRIMARY KEY
and you're done!
The only time I would say no primary key is needed is for things like temporary tables when bulk importing huge amounts of data, or other temporary scenarios.
Marc
You need a primary key to create relationships.
It's good practise to always design tables with primary keys, even if you add surrogate (auto increment identity).