locked
How to change a table witthout loosing my work? RRS feed

  • Question

  • Hello

    today I worked a full day (8 hours) on designing a quite complex (search) screnn. I added query parameters, designed the layout, added some code ...

    Then I came across a table field where I wanted to add a lookup list. So the advice I found in the internet: add a lookup table. I thought: OK this is a good idea. Doing so in the external SQL Server DB I use, is easy and  it certainly kept all my data (sql server would never do an action that would cause me to unintentinally loose data). I kept the data column name but changed it's type and added  a foreign key to a new table with the lookup data.

    Returned to VS 2012 Premium and used the update the data source function. In the entity the data structure change got reflected by adding a completely new colum (with a different type and name).

    To my very big suprise when i opened the screen referencing the entity the table, the query and all linked screen elements where GONE! Visual Studio simply deleted them! They will certainly not match the original entity structure any more but simply deleting them is DESTRUCTIVE. Strange enough: the source code does not get deleted - which is GOOD.

    I don't know what this is supposed to be good for. But deleting code (screen and query definitions are just as code) is NEVER right. Loosing 8 hours of work is BAD.

    Instead there should be a feature that when opening the screen/compiling, it tells me that the screen defintion and the data source do not match any more and give me a chance to fix it. Just like: the C# code does not match the data source any more: you need to fix it.

    Fortenately using Undo I could go back.

    Here is my question: how can I change the structure of an externa data source without getting the screens destroyed that references it?

    Regards

    Hansjörg Reister

    Robert Bosch GmbH

    Friday, October 4, 2013 4:05 PM

Answers

  • Hello,

    i think this not really feasible approach.

    I looked a little further into it. If you ADD a new column the problem does NOT occure.

    So don't do:

    1. rename a a column
    2. change it's data type (further investigation needed)
    3. add a foreign key

    Instead

    1.) add a new column

    2.) add a new column

    3.) add a new column

    I'll give it a try and see what happens if i now remove all references to the old column on the screen and then delete in the DB. This would be at least a workaround.

    But still: NEVER DELETE MY CODE! IT'S A SIN! :-)

    Hansjörg

    Friday, October 4, 2013 4:33 PM
  • hello,

    OK. Here is the good news. the workaround works!

    To change the column type:

    1. Add a new column with the new type
    2. Copy the data into that column
    3. Update the data source in VS Lightswitch
    4. Go the ALL the screens that use the entity and make sure you remove all screen elements that use the old column. Add screen elements for the new column
    5. SAVE ALL data, compile, test and CHECK IN or COPY ALL CODE to a backup folder
    6. Remove the old column in the data source
    7. Update the data source in VS Lightswitch
    8. Check your screens if everything is OK. In case of loosing stuff: either completely restore your code from the previous backup or try to merge (good luck: for me merging the XML files created by lightswitch NEVER worked).
    Robert Bosch GmbH

    Friday, October 4, 2013 4:41 PM

All replies

  • The only way I know of is to use a WCF RIA Service (that then talks to your external tables).

    You can update the WCF RIA Service (right-click and do an update, do not delete it and re-create it) and it will not destroy your screens that depend on it.

    See:

    Creating A WCF RIA Service Using Entity Framework

    WCF RIA Service (11)


    Unleash the Power - Get the LightSwitch HTML Client book

    http://LightSwitchHelpWebsite.com

    Friday, October 4, 2013 4:26 PM
  • Hello,

    i think this not really feasible approach.

    I looked a little further into it. If you ADD a new column the problem does NOT occure.

    So don't do:

    1. rename a a column
    2. change it's data type (further investigation needed)
    3. add a foreign key

    Instead

    1.) add a new column

    2.) add a new column

    3.) add a new column

    I'll give it a try and see what happens if i now remove all references to the old column on the screen and then delete in the DB. This would be at least a workaround.

    But still: NEVER DELETE MY CODE! IT'S A SIN! :-)

    Hansjörg

    Friday, October 4, 2013 4:33 PM
  • hello,

    OK. Here is the good news. the workaround works!

    To change the column type:

    1. Add a new column with the new type
    2. Copy the data into that column
    3. Update the data source in VS Lightswitch
    4. Go the ALL the screens that use the entity and make sure you remove all screen elements that use the old column. Add screen elements for the new column
    5. SAVE ALL data, compile, test and CHECK IN or COPY ALL CODE to a backup folder
    6. Remove the old column in the data source
    7. Update the data source in VS Lightswitch
    8. Check your screens if everything is OK. In case of loosing stuff: either completely restore your code from the previous backup or try to merge (good luck: for me merging the XML files created by lightswitch NEVER worked).
    Robert Bosch GmbH

    Friday, October 4, 2013 4:41 PM
  • Hello,

    i think this not really feasible approach.


    I am curious, why?

    Unleash the Power - Get the LightSwitch HTML Client book

    http://LightSwitchHelpWebsite.com

    Friday, October 4, 2013 4:55 PM
  • Hello

    1. Indirection: adds just another layer of the data source.That doesn't speed up things.
    2. Addtional cost: I need to host the OData service. That causes addtional costs. OK: i could do that on the same web server i run the lightswitch application. but in a managed IT environment an addtional web site causes addtional costs.
    3. Addtional effort to create the OData service causing addtional costs.
    4. Addtional complexity (causing addtional costs): in the professional world you have to pay people for developing, testing, fixing ... Every line of code I write (someone writes for me) costs money and adds complexity that I need to handle (maybe for a long time).

    It's not coding for fun around here.... (at home I do that).

    That's exactly why I did choose Lightswitch. Because it should drastically reduce the amount of code I / my team needs to write. And in general this is fullfiled very well.

    In the project that I currently working on I develop the Lightswitch part and a colleague from India (that we hired) develops another part in ASP.NET. The difference in efficiecy is HUGE. LS outperforms ASP.NET by a factor 5-10 in productivity.

    The only point I see at the momement is that it's just not as mature as ASP.NET. This case is one of the examples. Here simply a feature is (badly) missing. There are a couple of other areas that I feel need to be improved.

    I hope that LS will survive even if Silverlight might be out-of-focus at MS. But you never know. There is a big movement ongoing at MS.

    Friday, October 4, 2013 5:17 PM
  • Hello

    1. Indirection: adds just another layer of the data source.That doesn't speed up things.
    2. Addtional cost: I need to host the OData service. That causes addtional costs. OK: i could do that on the same web server i run the lightswitch application. but in a managed IT environment an addtional web site causes addtional costs.
    3. Addtional effort to create the OData service causing addtional costs.
    4. Addtional complexity (causing addtional costs): in the professional world you have to pay people for developing, testing, fixing ... Every line of code I write (someone writes for me) costs money and adds complexity that I need to handle (maybe for a long time).

    #2 should not be an issue, you don't host the OData Service, you create a project that creates a .dll that is exposed by LightSwitch as an OData service. You check the box that says "do NOT expose this directly as an OData service".

    On the other points, yes I see your point and even I avoid the hassle by creating my tables as internal tables even though I know that when I publish the application it will be to an existing table (I publish the app locally and then move the code to my production server and point it to the production tables in the web.config).

    However, when you have an external data source and you need to read and write to it then you need to add it as an external data source. When you do that, if you don't follow your steps carefully each time you can lose all your work, ouch!


    Unleash the Power - Get the LightSwitch HTML Client book

    http://LightSwitchHelpWebsite.com


    • Edited by ADefwebserver Friday, October 4, 2013 9:12 PM spelling
    Friday, October 4, 2013 5:36 PM