locked
What would cause 'Common Screen Set' not to provide an ADD screen? RRS feed

  • Question

  • I'm coming up to speed with LightSwitch so far and my first project is taking shape rather nicely. I'm down in the core of the web app and need to provide the functionality of from a browsed reference point open a new record either to Add, Browse, Update, or potentially delete(though this would be a remote possibility).  So I'm using the 'Common Screen Set' to add screens and it is only giving me a browse and view no edit or create.  Any idea what might be causing this???


    Ken Carter

    Tuesday, September 22, 2015 1:38 PM

Answers

  • There is most likely a problem with your PK, identity or unique constraints in whichever table is not editable from within LS.

    For best results with external db, I'd suggest having a single non nullable primarykey field IDENTITY(1,1) and also a rowversion field in every table.

    Like this:

    CREATE TABLE [dbo].[Accounts] ( [Id] INT IDENTITY (1, 1) NOT NULL, [RowVersion] timestamp NOT NULL, [CompanyName] NVARCHAR (255) NOT NULL, );

    CREATE TABLE [dbo].[Contacts] (
        [Id]          INT IDENTITY (1, 1) NOT NULL,

        [AccountId]   INT NOT NULL,

        [RowVersion]  timestamp     NOT NULL,
        [Name] NVARCHAR (255) NOT NULL
    );

    ALTER TABLE [dbo].[Contact] WITH NOCHECK
        ADD CONSTRAINT [FK_Contact_Account] FOREIGN KEY ([AccountID]) REFERENCES [dbo].[Account] ([ID]);
    GO

    HTH,

    Josh


    • Edited by joshbooker Wednesday, September 23, 2015 2:12 PM
    • Marked as answer by kencar Wednesday, September 23, 2015 5:51 PM
    Wednesday, September 23, 2015 1:23 PM

All replies

  • Is it a intrinsic database? Can you provide some more info

    Sven Elm

    Tuesday, September 22, 2015 6:33 PM
  • Sven,

     I'm not sure what you mean by 'intrinsic'.  It's pretty straight forward.  There is nothing particularly special about these tables that I can think of and what I'm doing here is not unlike what was done to get to the location where we are attempting to establish this relationship.

    I drew up this illustration to help give a picture of the objective:

    So the relationship stabled to get to the GETT_Element table is pretty much identical to the one that I am attempting to establish over to the GETT_DocGaps Table. 

    The articles will have multiple elements that will need to be documented. So there needs to be an ability to create one (and almost always more than one elements supporting an individual article found in the top table.  In addition to this, each of these elements will have supporting documentation and there may be one or more pieces of supporting documentation. Therefore, again this is a one to many relationship that is established that will need to have the ability for the user to create, modify and browse. multiple items in GETT_DocGaps.

    The handy little demos that show you how to use LightSwitch have you doing this but for some reason their example works and mine doesn't. They end up with add functionality, I don't.

    By the way ignore the arrows stating this works and this doesn't...that is related to the relationships that I'm building and an entirely different issue I'm dealing with in parallel. I drew the image for that and just am getting dual use out of it.

    Does this help?


    Ken Carter


    • Edited by kencar Tuesday, September 22, 2015 8:12 PM
    Tuesday, September 22, 2015 8:03 PM
  • Hi, I understand but did you manage to get the relation to work for docgaps. The relation must be set for the Common screen to add all functions like add or edit otherwise only browse or view will work. Intrinsic means the Lightswitch built in database

    Sven Elm

    Tuesday, September 22, 2015 8:49 PM
  • In that case no these tables were constructed outside of LightSwitch. I did that because I was architecting specific parameters around what was going to be placed in them such but I suppose I could go back and build the same structures inside of LightSwitch if that is an issue.

    Ken Carter

    Wednesday, September 23, 2015 11:57 AM
  • It is to be preferred. It becomes easier to manage relationships, etc.

    Sven Elm

    Wednesday, September 23, 2015 12:10 PM
  • Thanks Sven.. I'll focus on that this morning.

    Ken Carter

    Wednesday, September 23, 2015 12:12 PM
  • There is most likely a problem with your PK, identity or unique constraints in whichever table is not editable from within LS.

    For best results with external db, I'd suggest having a single non nullable primarykey field IDENTITY(1,1) and also a rowversion field in every table.

    Like this:

    CREATE TABLE [dbo].[Accounts] ( [Id] INT IDENTITY (1, 1) NOT NULL, [RowVersion] timestamp NOT NULL, [CompanyName] NVARCHAR (255) NOT NULL, );

    CREATE TABLE [dbo].[Contacts] (
        [Id]          INT IDENTITY (1, 1) NOT NULL,

        [AccountId]   INT NOT NULL,

        [RowVersion]  timestamp     NOT NULL,
        [Name] NVARCHAR (255) NOT NULL
    );

    ALTER TABLE [dbo].[Contact] WITH NOCHECK
        ADD CONSTRAINT [FK_Contact_Account] FOREIGN KEY ([AccountID]) REFERENCES [dbo].[Account] ([ID]);
    GO

    HTH,

    Josh


    • Edited by joshbooker Wednesday, September 23, 2015 2:12 PM
    • Marked as answer by kencar Wednesday, September 23, 2015 5:51 PM
    Wednesday, September 23, 2015 1:23 PM
  • Oh dear.....

    Well now I'm in the process of rebuilding the tables...

    So let me get this straight... Two objectives here so let me bring them together and pair them and pull back and try to take away the best of class result in your responses....

    1. My first issue was the one relationship wasn't kicking in.

    2. Next on the relationship that was the "Common screen set" wasn't including the Add, modify options to which Sven was indicating that I would need to build from inside of LS to get that functionality included.

    Now...

    If I could keep my existing tables I built (with no data in them) but they still would not have LS doing the heavy lifting for screen building and process construction because there were put together outside of LS that would be a strong enough negative to prompt me to continue with what I'm doing right now rebuilding the table structures inside of LS to give me the ADD SCREEN functionality I wanted.

    I look forward to the feed back.


    Ken Carter

    Wednesday, September 23, 2015 1:46 PM
  • LS will do the heavy lifting whether your tables are intrinsic or external as long as your external tables and relationships are solid. 

    I suspect there is an issue with one of your tables and relationships that is causing both of your problems.

    If LS cannot figure out what key or constraint makes your table rows unique then it considers the entity read-only and a bunch of stuff is 'turned off' such as AddEdit Screen capabilities.

    If you would prefer to have your tables external, as many of us prefer, then just make sure you have good keys and relationships in your table design.

    Modifying your tables in T-SQL (to add PKs, FKs and rowversion) and then Update Datasource in LS, should fix both of your problems.

    If you want more help with fixing you external table design, then I'd suggest scripting your tables and posting the CREATE TABLE T-SQL.

    HTH,

    Josh

    Wednesday, September 23, 2015 2:03 PM
  • Just to clarify a bit on the excellent advice Josh gave, adding Id and RowVersion fields to your tables is only necessary when creating them OUTSIDE of LightSwitch. When you add a table inside of your LightSwitch project through the Add Table button, these fields are created automatically, along with the Created/Modified/By fields.

    When you are creating a table through a script, tool, or directly on your SQL Server, perhaps to add Triggers, Indexes, and whatnot, then adding Id INT IDENTITY(1,1) NOT NULL and RowVersion TIMESTAMP NOT NULL will allow LightSwitch to treat them similarly to tables created inside LightSwitch (intrinsic tables in the ApplicationData space) Personally, I'd add the Created/CreatedBy and Modified/ModifiedBy fields too.

    If your external tables have no data in them, a simple ALTER TABLE to add the other fields may suffice, or it may be easier to start over with redefining the tables inside of LightSwitch.  Only you can determine how much work one approach over the other would be. 

    Wednesday, September 23, 2015 3:59 PM
  • You all have given me so much good information and I thank you so much for it! You've add 100x to my understanding of the table structure of the underlying databases for LS and that will be key to the things that I anticipate doing with the tool.  Big bump.. HUGE! Thanks so much.  I'm not sure which answer to mark as 'The answer' here but I'll do that here shortly; because there has been contributions from every corner.

    Wonderful input.  Greatly appreciated!


    Ken Carter

    Wednesday, September 23, 2015 5:51 PM