locked
Idenifying conflicts in relationships RRS feed

  • Question

  • Okay this is a strange one.. Or at least is seems like it is to me. I'm trying to setup a relation ship and getting the following error:

    I went back and verified on the link mapping that this was not the case that there are no links that would have been coming out of either of these table related to the Element_Sub value. It's frustrating being so close to the finish line but so far away at the same time!!


    Ken Carter

    Tuesday, September 22, 2015 4:24 PM

Answers

  • You don't have to recreate tables in LS, you must however get your keys and relationships setup right in the external db so LS is happy.The fact that the PK fields and FK field is the same name should not be the problem.  Rather I think this error is because you have the same field listed twice from the Primary table. 

    What PK indentity or unique constraints in SQL do you have on the primary table?

    • Proposed as answer by Angie Xu Monday, October 5, 2015 8:36 AM
    • Marked as answer by Angie Xu Tuesday, October 6, 2015 8:16 AM
    Wednesday, September 23, 2015 1:05 PM

All replies

  • I thought I would add this drawing because it really doesn't make any sense.  The same relationship exists as at the very next level up and it works perfectly.

    The One to Many relationship getting you to GETT_Element table and the screen that displays it is of no architectural significance difference from that of the attempted relationship that I'm trying to build above between GETT_Element and GETT_DocGaps.  Both uses Key fields on both sides that have not been used elsewhere but for some reason the tool thinks that there is a reason to reject this linkage.


    Ken Carter

    Tuesday, September 22, 2015 8:09 PM
  • If you are using the built in database builder in LS the relation is set by LS. This looks like you are using an attached database or am I wrong?

    Sven Elm

    Tuesday, September 22, 2015 8:55 PM
  • No you are correct as I responded in the other thread.  In this case it really doesn't matter as I can re-engineer the same table structures inside of LightSwitch (it is going to be a bit clumsy to do so but possible), but that points out an "Achilles Heel" in that it severally limits LightSwitch development to only projects where there is no preexisting data or where data can be later imported into the structures built up that are a result of the development.  That would bring into question the value of the tool as it loads more processing time on the back side of the project rather than the front side for those sort of efforts.

    So What I'm hearing is that I need to go back and recreate my two tables building them inside of LS in order to get this functionality out of LS.  I'm fine with understanding that going forward. I simply wasn't aware of that caveat. 

    Here is a follow up question however. There must be a manual means to do this. Are there any illustrations on how to do so that someone can point me to? If not I will just have to build up some of my own.

    

    Ken Carter

    Wednesday, September 23, 2015 12:10 PM
  • You don't have to recreate tables in LS, you must however get your keys and relationships setup right in the external db so LS is happy.The fact that the PK fields and FK field is the same name should not be the problem.  Rather I think this error is because you have the same field listed twice from the Primary table. 

    What PK indentity or unique constraints in SQL do you have on the primary table?

    • Proposed as answer by Angie Xu Monday, October 5, 2015 8:36 AM
    • Marked as answer by Angie Xu Tuesday, October 6, 2015 8:16 AM
    Wednesday, September 23, 2015 1:05 PM
  • Agree with Josh. If I had existing data in my tables I would stick to what you are doing. Sorry for missleading you. Good luck

    Sven Elm

    Wednesday, September 23, 2015 1:22 PM
  • I should note for the benefit of future readers that while this was the answer the way it was achieved was to reconstruct the Legacy tables to provide the necessary primary keys LS required. Once Josh had provided me with the requirements that I was missing, I surmised the quickest path to resolution was to rebuild rename the old structures recreate them in the proper configuration, then copy the data over to the new structure so that it would be LS friendly. 

    At that point I was able to mark this as an answer to the issue once my table had the proper key structure to support the function.

    Again... Many thanks to Josh and all who assisted abbreviating my learning curve on legacy data integration with LS.


    Ken Carter

    Monday, October 5, 2015 12:05 PM