Published to Azure, can't browse one of my tables in the app (though it's in SQL Azure??) RRS feed

  • Question

  • Has anyone run across this before?  I'm using VS 2013 and have written a LS HTML tracking app with the typical SQL backend.  

    One of my tables has a browse screen associated with it, and after I publish and go to that screen nothing appears, I get the 'no items' message.

    I have a post restore script that deletes and seeds the database and tables, it's worked fine for me in the past.  Recently I added and linked a child  table to this mysterious no-data table and have updated the post restore script appropriately.  This isn't the first time I've linked a child table to this table.

    The kicker here is I *do* see the records in my browse screen when I build locally and run the app.  Going to the SQL Azure portal,  the table in question is populated with the most current data.  (I changed a few values in the post-restore script to test things out, published, and sure enough those modified values are in my SQL Azure table.)

    This appears to be the only table in this situation as far as I can tell.  All other screens are running fine and as expected.  Opening the F12 developer tools and looking at the javascript console shows nothing unusual when opening this browse screen.  I'm stumped and open to suggestions.

    Monday, March 16, 2015 6:33 AM


All replies

  • The data may not show because of LightSwitch applying a rule. Likely some property is mandatory but has null, could be a relationship such as 1-to-Many, that should be 0..1-to-Many.


    Dave Baker | AIDE for LightSwitch | Xpert360 blog | twitter : @xpert360 | Xpert360 website | Opinions are my own. For better forums, remember to mark posts as helpful/answer.

    Monday, March 16, 2015 9:22 AM
  • Thanks Dave, that's definitely a possibility here and worth checking out. I'll report back with updates.

    Are there ways to debug this once it all hits Azure?  Odd that the rule would be troublesome there but not locally, my sql post deploy script deletes from all tables and repopulates them.

    Monday, March 16, 2015 3:55 PM
  • I'm still skunked a week later.  I looked at my table and updated it so that it has no null values in any column that allows for it.  Still can't see anything on my browse screen in Azure, but can locally.

    Michael Washington tipped me off a few hours ago to how to set breakpoints and debug while in Azure, but I'm not sure in this instance *where* to put the breakpoint?  And does anyone else have a notion on what might be going on?  

    Maybe the most frustrating part of this is after rebuilding and running my post SQL deployment script locally everything works fine, but after publishing to Azure I can't see anything-- on that one browse screen.  All others are fine.

     Not sure what would be different about Azure in this scenario vs the local box?  Same post restore script is being run in both environments, and I know by looking at SQL Azure the records are making it into the database up there...

    Saturday, March 21, 2015 10:45 PM
  •  I'm not sure in this instance *where* to put the breakpoint?  And does anyone else have a notion on what might be going on?  

    For this you may need tracing:

    Diagnosing Problems in a Deployed 3-Tier LightSwitch Application

    Tracing: Debugging Your LightSwitch Application In Production

    Unleash the Power - Get the LightSwitch 2013 HTML Client / SharePoint 2013 book


    • Marked as answer by jim bancroft Monday, March 23, 2015 4:53 AM
    Sunday, March 22, 2015 1:50 PM
  • Thanks Michael.   I turned on the tracing, as outlined in the articles, and it gave me a good view into the screens and such as they were loading.

    However nothing amiss showed up, all seemed fine in the trace log.  I did try to access my 'Incidents' table directly via the OData endpoint and no data returned, whereas all my other tables did have data.

    That made me think (for once)...I went back to my solution and set a breakpoint in the Incidents_Filter method, meaning the filter method that comes standard for all tables.  Sure enough, I had some code in there that only showed data for people in the 'Administrator' group and/or the default, VS2013 'TestUser' account that comes out of the box with all LS solutions.  

    A week prior, I showed a coworker how to use the DesktopClient interface to set up groups and roles. We somehow inadvertently changed the 'Administrator' group to 'Administrators' during the tutorial.  Aaaargh!

    So when running locally under the TestUser account, things were fine, but in Azure the filter kept out all the data for this table since no one was in that 'Adminstrators' group.  The breakpoints tip Michael gave me earlier tripped the wire, but the tracing information helped too, and will be a very useful addition to the toolbox.  


    Monday, March 23, 2015 4:51 AM
  • Monday, March 23, 2015 12:26 PM