Skip to main content
Solved

Write to relation table in other than FileGDB


sigtill
Supporter
Forum|alt.badge.img+24

Similar to FileGDB (https://knowledge.safe.com/questions/1652/writing-relationships-in-esri-file-geodatabase.html)

Is it possible to easily write to a relation-table on MS SQL? And other databases? I see the db_relationship does not exist in those formats

Best answer by takashi

Hi @sigtill, I sometimes add a foreign key constraint to tables with a SQL statement written in the 'SQL Statement to Execute After Translation' parameter for the database writer. e.g.

alter table table1
add constraint fk_table1_table2 foreign key (id)
references table2 (id);
View original
Did this help you find an answer to your question?

8 replies

takashi
Influencer
  • Best Answer
  • September 1, 2016

Hi @sigtill, I sometimes add a foreign key constraint to tables with a SQL statement written in the 'SQL Statement to Execute After Translation' parameter for the database writer. e.g.

alter table table1
add constraint fk_table1_table2 foreign key (id)
references table2 (id);

sigtill
Supporter
Forum|alt.badge.img+24
  • Author
  • Supporter
  • September 1, 2016
takashi wrote:

Hi @sigtill, I sometimes add a foreign key constraint to tables with a SQL statement written in the 'SQL Statement to Execute After Translation' parameter for the database writer. e.g.

alter table table1
add constraint fk_table1_table2 foreign key (id)
references table2 (id);
Well, I need to insert to table1 first, then the join table1-2, then the features in the table2. So using your approach might not work? Would be great if you could do it the same way as with FileGDB.  

 

 


david_r
Evangelist
  • September 1, 2016

Relationships in traditional SQL databases (non-SDE) work a bit differently than in e.g. a FileGDB, there is no such thing as a relationship-table. The relationships between two tables are defined with foreign key constraints only, the relationships aren't materialized in separate entities.

If we use Takashi's example, it means that you'll first have to write the data in "table2" before you can write the data to "table1", since it references "table2". In FME this often means having to use two writers, one for "table1" and one for "table2", then making sure that "table2" is written first by having it at the top of the Navigator.

If you think this is a hassle, consider voting for the idea I posted earlier today :-)

Let me know if I've misunderstood your question.


takashi
Influencer
  • September 1, 2016
sigtill wrote:
Well, I need to insert to table1 first, then the join table1-2, then the features in the table2. So using your approach might not work? Would be great if you could do it the same way as with FileGDB.  

 

 

If the table1 and table2 will be created by the same workspace, you can create the tables and define their relationships (all the constraints) through the 'SQL Statement to Execute Before Translation'. e.g.

 

FME_SQL_DELIMITER ;

create table table1 (
  id integer,
  something varchar(100)
  constraint pk_table1 primary key (id)
);

create table table2 (
  id integer,
  something varchar(100)
  constraint pk_table2 primary key (id),
  constraint fk_table2_table1 foreign key(id) references table1 (id)
);
In this case, be aware that the schema definitions in the writer feature types should exactly match the CREATE statement.

takashi
Influencer
  • September 1, 2016
sigtill wrote:
Well, I need to insert to table1 first, then the join table1-2, then the features in the table2. So using your approach might not work? Would be great if you could do it the same way as with FileGDB.

 

 

How about this? There may be some variations depending on the timing for creating the tables.

 


mark2atsafe
Safer
Forum|alt.badge.img+44
  • Safer
  • September 1, 2016
david_r wrote:

Relationships in traditional SQL databases (non-SDE) work a bit differently than in e.g. a FileGDB, there is no such thing as a relationship-table. The relationships between two tables are defined with foreign key constraints only, the relationships aren't materialized in separate entities.

If we use Takashi's example, it means that you'll first have to write the data in "table2" before you can write the data to "table1", since it references "table2". In FME this often means having to use two writers, one for "table1" and one for "table2", then making sure that "table2" is written first by having it at the top of the Navigator.

If you think this is a hassle, consider voting for the idea I posted earlier today :-)

Let me know if I've misunderstood your question.

You can - with 2016 - set the order in which connections fire. Maybe that would help? You could have a single writer and two tables written in order. You might need to have the two connections emerge from the same transformer, which would complicate things.

 

 


david_r
Evangelist
  • September 1, 2016
mark2atsafe wrote:
You can - with 2016 - set the order in which connections fire. Maybe that would help? You could have a single writer and two tables written in order. You might need to have the two connections emerge from the same transformer, which would complicate things.

 

 

That's great to hear, Mark. I think this new functionality has escaped me a bit, do you have any pointers that explains it in more detail?

sigtill
Supporter
Forum|alt.badge.img+24
  • Author
  • Supporter
  • September 1, 2016

Thanks for the answers! I had an option similar to Takashis, however I struggled with the Featurewriter finishing before starting to use the writer. Using the Creator Featuremerger solves that issue, thanks @takashi


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings