Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Ok given the further clarification here is what I would do.</p> <p>staying in line with the concern raised by GraemeF, doing what you want is brittle and prone to breaking at best.</p> <p>Because of this the general practice is to treat design time data support as a wholly different approach then runtime data support. Very simply, the coupling you are creating between your design time environment and this DB is a bad idea.</p> <p>To simply provide design time data for visualization I prefer to use a mock class that adheres to a common Interface as the runtime class. This gives me a way to show data that I can ensure is of the right type and conforms to the same contract as my runtime object. Yet, this is a wholly different class that is used for design time support (and often used for Unit Testing).</p> <p>So for example. If I had a run time class that needs to show person details such as first name, last name and Email:</p> <pre><code>public class Person() { public String FirstName { get; set;} public String LastName {get; set;} public Email EmailAddress {get; set;} } </code></pre> <p>and I was populating this object from a DB at runtime but also need to provide a design time visualization I would introduce an IPerson interface that defines the contract to adhere to, namely enforces that the property getters exist:</p> <pre><code>public interface IPerson() { String FirstName { get; } String LastName { get; } Email EmailAddress { get; } } </code></pre> <p>Then I would update my runtime Person class to implement the interface:</p> <pre><code>public class Person() : IPerson { public String FirstName { get; set;} public String LastName {get; set;} public Email EmailAddress {get; set;} } </code></pre> <p>Then I would create a mock class that implements the same interface and provides sensible values for design time use</p> <pre><code>public MockPerson() : IPerson { public String FirstName { get { return "John"; } } public String LastName { get { return "Smith"; } } public Email EmailAddress { get { return new Email("John@smith.com"); } } } </code></pre> <p>Then I would implement a mechanism to provide the MockPerson object at design time and the real Person object at runtime. Something like <a href="http://blog.bradcunningham.net/2009/05/sharing-mock-data-for-unit-tests-and.html" rel="nofollow noreferrer">this</a> or <a href="http://blog.bradcunningham.net/2008/11/mock-data-in-blend-using-custom-markup.html" rel="nofollow noreferrer">this</a>. This provides design time data support without the hard dependency between the runtime and design time environments. </p> <p>This pattern is much more flexible and will allow you to provide consistent design time data support throughout your application.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow do I get the application's directory from my WPF application, at design time?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USBrad Cunningham
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    1. COWhy do I have to settle for a mock solution? I don't want to see that table populated with garbage at design time, I want that every time I cast an eye on it to be able to see the real data even before I recompile my project. I might happen to work on some other part of the project and actually need that data to make a decision there without having to recompile. It's much more convenient to just have it there, with all its associated transformations, displayed as I want it at design time, rather than gleaning it out of the database.
      singulars
      1. PO
      1. USluvieere
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload