I'm hoping to display a multi-valued column in a tabular UI format. By multi-valued column, I mean a column in which a single cell can simultaneously have multiple values -- aka a list of values. These values might be drawn from a short list of possibilities (e.g. an enumeration) or from a long list (e.g. another table). Imagine a table of contacts with a "friends" column that can refer to zero or more other contacts.
I need the ability to add new values, remove values, and ideally the values would be listed horizontally and word wrapped. I have a feeling that no out-of-the-box datagrid control on the planet can do this, but I figured this is the right forum to ask such a question.
I'm guessing that the current state of the art is to display the information in a form, not in a table (e.g. "details" of a row). However, we would like to actually display the values in a column of the table in a horizontally wrapped, in-line editable fashion. At this time, we are planning to use WPF, so I'm hoping for a WPF solution.
WPF is definitely the right tool for this job. I don't think you'll find it very difficult to get the layout you want once you understand a few core WPF concepts (mostly binding and DataTemplates). I would suggest maybe a ListView/GridView with a GridViewColumn with a custom CellTemplate containing an ItemsControl with its own DataTemplate...Simple, really ;-)
Related
I am working to make a dashboard in MS PowerView but having some trouble creating "slicers" for my dashboard. A slicer is basically a filter for the whole dashboard which filters out the whole display based on what is selected. For example, I am working with a survey so if we click on person type 1 under the "person" slicer, only responses from person type 1 will show.
I am trying to make a slicer based on statistical measure type. Basically, I want a slicer with 3 different statistical measures: average, median, and mode. So when "average" is selected only those graphs using the measure of "average" will display.
So far, all I have is a table in MS Access called "measure name" and I have made this a slicer on my table. However, in order for my slicer to work I believe I have to use a DAX formula. Any idea how to do this? I have tried
if(MeasureName[MeasureType] = "Average") but I'm not sure what to put for the true and false.
Any feedback would be appreciated!! :)
You can make a slicer that allows users to choose the measure to be shown in charts on the canvas. But as Rory said, you cannot use it to show/hide graphs. It would just change the measure used in the graphs.
Jason Thomas has a good blog post on creating a slicer to choose measures in Power Pivot. It works similarly in a Tabular model.
Create a table of measures with an ID column.
Create a measure based on that table to find the minimum ID value from the slicer selection. This tells you which measure is chosen.
Replace the measures in your charts with this new measure.
I don't consider this to be against Kimball at all. It has less to do with the dimensional model and more to do with the technological solution required for the desired UI capabilities. Basically, you can have your dimensional model and have this table out outside of that without feeling like you are breaking the rules.
A slicer is usually an attribute of one of your dimensions. When you filter on that attribute the filter applies also to your fact table. So if you have a dimension with three entries: average, median and mode it would be possible to create one fact table that stacks the average, median and mode values so that when the slicer is clicked the fact table is filtered for that attribute.
That will allow you to show the three types on one graph. It won't allow you to show some graphs and not others. And this type of fact table kind of goes against what Kimball might say about fact table design ...
I have a view showing two tables which data is coming from same model but based on different column status I divided in 2 tables. Problem is, when I click on top table's column name heading for sorting, it also sort the bottom tables. I'm wanting the bottom table data won't sort when I click on top table column heading title. If any one have a good solution, would highly appreciated.
This highly depends on your setup, but you're going to have to do some custom code.
For example, don't allow Cake to sort for you. See what the links look like when created by Cake, then write your own, and include an additional variable &table=1 or something.
Based on the sort variable and the table variable, build your pagination options for each including the correct sort you want for each group separately.
Another option (depending on how large your data sets are) is to use javascript datatables.
I am looking to create an attendance sheet but not getting the magic idea for the same. Possible options for me
Use grid but done know how to pass date values as grid column headings
Use table but don’t know how to edit the same. grid is editable component.
Please help me with the thought process
I don't think that Ext.grid.Panel is the component for this purpose. Grid conceptually more resembles database tables (fixed columns/fields repeated many times in rows/records) than spreadsheets (cells w/o prescribed purpose).
Also, grid has a lot of features like sorting, column re-ordering, column hiding that you would need to turn off for this purpose. Grid is just an overkill.
I would probably go with a custom table-like form with checkboxes. The form would be dynamically generated as employees can change and dates as well.
I'm creating a database with Access. This is just a test database, similar to my requirements, so I can get my skills up before creating one for work. I've created a database for a fictional school as this is a good playground and rich data (many students have many subjects have many teachers, etc).
Question 1
What is the difference, if any, between using a Lookup column and a many-to-many associate table?
Example: I have Tables 'Teacher' and 'Subject'. Many teachers have many subjects. I can, and have, created a table 'Teacher_Subject' and run queries with this.
I have then created a lookup column in teachers table with data from subjects. The lookup column seems to take the place of the teacher_subject table. (though the data on relationships is obviously duplicated between lookup table and teacher_subject and may vary). Which one is the 'better' option? Is there a snag with using lookup tables?
(I realize that this is a very 'general' question. Links to other resources and answers saying 'that depends...' are appreciated)
Question 2
What attracts me to lookup tables is the following: When creating a form for entering subjects for teachers, with lookup I can simply create checkboxes and click a subject for a teacher 'on' or 'off'. Each click on/off creates/removes a record in the lookup column (which replaces teacher_subject).
If I use a form from a query from teacher subject with teacher as main form and subject as subform I run into this problem: In the subform I can either select each subject that teacher has in a bombo box, i.e. click, scroll down, select, go to next row, click, scroll down, etc. (takes too long) OR I can create a list box listing all available subjects in each row but allowing me to select only one. (takes up too much space). Is it possible to have a click on/off list box for teacher_subject, creating/removing a record there with each click?
Note - I know zero SQL or VB. If the correct answer is "you need to know SQL for this" then that's cool. I just need to know.
Thanks!
Lookup columns in tables will cause you more stress than joy. Unless you need them for Sharepoint, they should be avoided. You may wish to read http://r937.com/relational.html and http://www.mvps.org/access/tencommandments.htm
I wouldn't use them. Your example is fine, but there are limitations. What do you do when you need to reference another field from the Subject table other than the name? How would you differentiate subjects that are only offered on a semester basis?
You have no way of getting a count of how many subjects each teacher is assigned without some ugly coding.
Another limitation, is when you start identifying who taught what courses during a given school year.
I'm kind of unclear on your second question, but it sounds to me like you need a subform with a dropdown list.
If you want to do the checkbox thing, it quickly becomes a lot more complicated. To me, you're starting from user interface and working backwards to structure, instead of going the other direction.
I hesitate to mention it, but in terms of full disclosure you should know that in A2007 and A2010, you have multi-value fields available, and they are presented with exactly the UI you describe. But they have many of the same problems as lookup fields, and are quite complex to work with in code. Behind the scenes, they are implemented with a standard many-to-many join table, but it's all hidden from you.
I wish MS would make the listbox with checkbox control that is used with MV fields available for all listboxes, but binding that to a many-to-many join table would be complex if the listbox control were not designed for that (with link child/link master properties, for instance).
I tried to come up with a way to offer you the UI feature you prefer from multi-value fields without actually using multi-value fields. That seems challenging to me.
The closest I could come up with is to load a disconnected recordset with your "List" choices and a check box field. Then create a form, or subform, based on that recordset which you present in datasheet view. It could look similar to a combo bound to a multi-value field. In the after update event of the checkbox field, you would need code to add or remove a record from the junction table as required.
However, I don't know if this is something you would care to tackle. Earlier you indicated a willingness to learn SQL if needed; the approach I'm suggesting would also require VBA. Maybe take a look at Danny Lesandrini's article, Create In-Memory ADO Recordsets, to see whether it is something you could use.
OTOH, maybe the most appropriate answer for you is to keep the multi-value fields and get on with the rest of your life. I'm stuck. But now that we know you are actually using multi-value fields, perhaps someone else will be able to offer you a more appropriate suggestion.
I would like to change the "Row Source" values in an Access table through code.
This way I can filter what a user can choose in a column's combo box.
In line with Dave DuPlantis' answer, you may wish to read "The Evils of Lookup Fields in Tables" From the Access Web by various Microsoft Access MVPs.
I don't know whether or not this is an option for you, but I would recommend separating the table and filtering options, setting up a form to do the data entry and modification and using code to set the Row Source for the combo box on the form. As you've already seen, while Access does provide the opportunity to treat tables as more than just tables, that is primarily for GUI purposes. Behind the scenes, Access prefers that you work with forms for data entry.
If you need to pursue the table method, you might try looking at the MS knowledge base articles referenced here. (The kb articles are here and here.) Keep in mind that these refer to Access 97 and may no longer be relevant. I wasn't able to find any more recent references to those properties in an Access tabledef.
Your question is quite confusing. "RowSource" is a property of a list box or combo box. A table does not have a RowSource, but, as Remou points out, Access allows you to define fields in your tables so that they display a combo box that looks up values from a related table. This combo box has a rowsource, so it's perhaps what you mean, but it's simply a terrible idea.
That combo box that you define in the table design is a user interface object, and UI doesn't belong in your table definitions. Not only does it lead to all sorts of problems, but it means your tables themselves can be broken by changes to other tables that invalidate the definition of the lookup fields.
User interface controls belong in user interface objects, which means that you should be putting them only in forms (or, at the lowest level, in saved queries).
Filtering for a user is, again, a user interface issue, and not one that has anything to do with table design.