I am creating a report which contains 3 parameters COUNTRY, STATE, and CITY. I have already created a cascade parameterized report which means the CITY result is based on the STATE result and the STATE result is based on the COUNTRY result. But what I want now is, in the same report and parameters if I just choose only COUNTRY or only STATE or only CITY, I want results as well. It should not give me any errors. That means if I only choose country and run the report it should show the result and the same with STATE and CITY. On the other hand, cascade parameters should also be active. Is it possible? If yes what will be the process and if not what would be the best option? The page will be used by multiple users throughout the website. Do I need to work on the code or the SSRS report or both?
You should be able to do this easily (I think)...
You already have Country -> State -> City setup and I'm assuming the query for the available values will be something like...
SELECT State from myTable WHERE Country IN(#Country)
... and so on.
I'm also assuming that your final dataset query, the one that actually gets the report data have a WHERE clause that filters on City. e.g.
SELECT * FROM myMainTable WHERE City in (#City)
So, all you should need to do is to set the default parameters to the same dataset query as the available values.
When the report runs, all Countries will be selected, which means all states will be available/selected and therefore all cities will be available/selected.
There is also another, more complicated method which means the user chooses what to filter on first and then makes selections which in turn populate the next drop down but I think it's probably overkill. If this sounds of interest though, let me know and I'll dig out the answer I wrote a while back for somebody else.
I have a report that returns the description of a product sheet from the product reference.
The product sheet contains: the description of the product, dates, the history of the product, ...
The data comes from a stored procedure called with a SINGLE reference.
The report criterion is currently a single reference.
So everything is ok.
I would like to pass a list of references separated by, for example, a comma and run the PS as many times as there are references to query and make as many product sheets as references.
I hope i was clear.
A big thank you for your answers.
It sounds like you already have a report that produces a result for a single reference. If that is true then the easiest way is probably to use your existing report as a subreport.
In brief...
You will need to create a new report, add a dataset that contains a unique list of references that you want to produce reports for (this could be parameterized too if required).
This might be as simple as SELECT DISTINCT RefID FROM myTable
Next add a list control to your report and set its dataset property to the dataset you created above.
In the list's 'cell' right-click and insert a subreport. Now right-click the subreport placeholder and set subreport to be the name of you original report. Set the parameter to be the fields from your dataset above (in this exmaple [RefID]).
The list will produce one subreport per entry in the dataset. You can set page breaks from the list control if required.
If this does not help, let me know and I'll update the answer with more details.
I am currently creating a simple report in Crystal Reports with two tables:
{Table1.group_name_id} --> {Table2.technical_group_id}
Table 1 holds all of the groups; ID's, Names etc
Table 2 holds only the technical groups ID
With these two tables linked it means the only records that will return are those where technical groups are involved, perfect! But now I want to add a dynamic parameter to return the Technical Group Names for the End User to select.
Because {Table2} only holds one field (the ID) which links to {Table1}'s ID, I have to perform the Parameter selection on {Table1}'s name field.
But this is pulling back all of {Table1}'s names and is discounting the Join on {Table2} even with an enforced join present.
Is there a way to force it to only pull back {Table1}'s names as long as it matches the JOIN between {Table1} and {Table2}?
Thanks in advance!
Edit (additional information)
As I thought - the problem was Crystal Reports was not recognising the JOIN when displaying the parameter values.
After some reading, I found out that the JOINS are only recognised when the query is passed to the database (logically). So when selecting a Parameter, it doesn't recognise the JOINS.
I got around this by creating a custom SQL command, forcing it to only pull back the groups in the second table.
First, please confirm your join INNER JOIN.
For Addition,
You can pass the User Input as a parameter in to the crystal report and use this {#Parameter} to filter the result set using SelectionFormula in Crystal Report.
Or you can even set the selectionformula itself from the application.
I've been using cakephp for a while, but have not learned all the ins and outs yet so I may be missing something simple. Or the problem may lie with my database structure. Either way, if anyone has any idea of what I'm doing wrong, please share.
Is there a way to order the data returned by cakephp's find using values stored in another table?
I am creating custom form fields on a per category basis, so when I choose a particular category to post in, custom fields will be added to my form. I have 3 tables: Posts, Fields, and Answers. The Posts table stores the basic static information for the post, such as id, category_id, title, and description. The Fields table stores the custom field data, such as category_id, field_label, field size, etc. The Answers table stores the values that are entered for particular fields, such as post_id, field_id, value.
I am trying to display the posts for a particular category, and create html table headers on the fly, using select fields, set by a column toggle in the fields table, and also select the answers associated with that particular field and post.
I am able to select all the data I want, and paginate everything just fine, but what I can't seem to figure out is how to order the data using one of the dynamic column values. For example, if I have year, make, and model as 3 custom fields, I would like to click the year column to sort my results by the year values, and if I click the make column, I would like to sort my results by the make values, etc.
I know how to order the results by a particular field inside the posts table, such as id or title, but is it possible to order using the custom fields? Am I setting up the database and/or something else wrong, and if not is there are particular cakephp method or sql command that I need to use in order to sort by the custom fields? I'm not really well versed in complex sql commands.
Thanks.
I'd suggest you pass the field name and sort direction in the URL (GET param). So when you have your table header link, form it so that it links to a URL as so:
http://somesite.com/pages/index/sort:customfield1/dir:asc
Then when you're grabbing the data from the db in your find() query, include the named parameters as the order parameter that can be sent to find.
You'll need to determine a default sorting column and direction. Maybe have that be selectable with a boolean field in the schema -- if there are no parameters sent to the action above, pull the field from your other table that has default set to true in the record.
To clarify: when a user visits a given action, first you'll pull the custom fields from the other table. Then using those fields (either the default as mentioned above, or the named params passed in the URL) form the query for the actual data, using the order parameter.
I have an application with multiple "pick list" entities, such as used to populate choices of dropdown selection boxes. These entities need to be stored in the database. How do one persist these entities in the database?
Should I create a new table for each pick list? Is there a better solution?
In the past I've created a table that has the Name of the list and the acceptable values, then queried it to display the list. I also include a underlying value, so you can return a display value for the list, and a bound value that may be much uglier (a small int for normalized data, for instance)
CREATE TABLE PickList(
ListName varchar(15),
Value varchar(15),
Display varchar(15),
Primary Key (ListName, Display)
)
You could also add a sortOrder field if you want to manually define the order to display them in.
It depends on various things:
if they are immutable and non relational (think "names of US States") an argument could be made that they should not be in the database at all: after all they are simply formatting of something simpler (like the two character code assigned). This has the added advantage that you don't need a round trip to the db to fetch something that never changes in order to populate the combo box.
You can then use an Enum in code and a constraint in the DB. In case of localized display, so you need a different formatting for each culture, then you can use XML files or other resources to store the literals.
if they are relational (think "states - capitals") I am not very convinced either way... but lately I've been using XML files, database constraints and javascript to populate. It works quite well and it's easy on the DB.
if they are not read-only but rarely change (i.e. typically cannot be changed by the end user but only by some editor or daily batch), then I would still consider the opportunity of not storing them in the DB... it would depend on the particular case.
in other cases, storing in the DB is the way (think of the tags of StackOverflow... they are "lookup" but can also be changed by the end user) -- possibly with some caching if needed. It requires some careful locking, but it would work well enough.
Well, you could do something like this:
PickListContent
IdList IdPick Text
1 1 Apples
1 2 Oranges
1 3 Pears
2 1 Dogs
2 2 Cats
and optionally..
PickList
Id Description
1 Fruit
2 Pets
I've found that creating individual tables is the best idea.
I've been down the road of trying to create one master table of all pick lists and then filtering out based on type. While it works, it has invariably created headaches down the line. For example you may find that something you presumed to be a simple pick list is not so simple and requires an extra field, do you now split this data into an additional table or extend you master list?
From a database perspective, having individual tables makes it much easier to manage your relational integrity and it makes it easier to interpret the data in the database when you're not using the application
We have followed the pattern of a new table for each pick list. For example:
Table FRUIT has columns ID, NAME, and DESCRIPTION.
Values might include:
15000, Apple, Red fruit
15001, Banana, yellow and yummy
...
If you have a need to reference FRUIT in another table, you would call the column FRUIT_ID and reference the ID value of the row in the FRUIT table.
Create one table for lists and one table for list_options.
# Put in the name of the list
insert into lists (id, name) values (1, "Country in North America");
# Put in the values of the list
insert into list_options (id, list_id, value_text) values
(1, 1, "Canada"),
(2, 1, "United States of America"),
(3, 1, "Mexico");
To answer the second question first: yes, I would create a separate table for each pick list in most cases. Especially if they are for completely different types of values (e.g. states and cities). The general table format I use is as follows:
id - identity or UUID field (I actually call the field xxx_id where xxx is the name of the table).
name - display name of the item
display_order - small int of order to display. Default this value to something greater than 1
If you want you could add a separate 'value' field but I just usually use the id field as the select box value.
I generally use a select that orders first by display order, then by name, so you can order something alphabetically while still adding your own exceptions. For example, let's say you have a list of countries that you want in alpha order but have the US first and Canada second you could say "SELECT id, name FROM theTable ORDER BY display_order, name" and set the display_order value for the US as 1, Canada as 2 and all other countries as 9.
You can get fancier, such as having an 'active' flag so you can activate or deactivate options, or setting a 'x_type' field so you can group options, description column for use in tooltips, etc. But the basic table works well for most circumstances.
Two tables. If you try to cram everything into one table then you break normalization (if you care about that). Here are examples:
LIST
---------------
LIST_ID (PK)
NAME
DESCR
LIST_OPTION
----------------------------
LIST_OPTION_ID (PK)
LIST_ID (FK)
OPTION_NAME
OPTION_VALUE
MANUAL_SORT
The list table simply describes a pick list. The list_ option table describes each option in a given list. So your queries will always start with knowing which pick list you'd like to populate (either by name or ID) which you join to the list_ option table to pull all the options. The manual_sort column is there just in case you want to enforce a particular order other than by name or value. (BTW, whenever I try to post the words "list" and "option" connected with an underscore, the preview window goes a little wacky. That's why I put a space there.)
The query would look something like:
select
b.option_name,
b.option_value
from
list a,
list_option b
where
a.name="States"
and
a.list_id = b.list_id
order by
b.manual_sort asc
You'll also want to create an index on list.name if you think you'll ever use it in a where clause. The pk and fk columns will typically automatically be indexed.
And please don't create a new table for each pick list unless you're putting in "relationally relevant" data that will be used elsewhere by the app. You'd be circumventing exactly the relational functionality that a database provides. You'd be better off statically defining pick lists as constants somewhere in a base class or a properties file (your choice on how to model the name-value pair).
Depending on your needs, you can just have an options table that has a list identifier and a list value as the primary key.
select optionDesc from Options where 'MyList' = optionList
You can then extend it with an order column, etc. If you have an ID field, that is how you can reference your answers back... of if it is often changing, you can just copy the answer value to the answer table.
If you don't mind using strings for the actual values, you can simply give each list a different list_id in value and populate a single table with :
item_id: int
list_id: int
text: varchar(50)
Seems easiest unless you need multiple things per list item
We actually created entities to handle simple pick lists. We created a Lookup table, that holds all the available pick lists, and a LookupValue table that contains all the name/value records for the Lookup.
Works great for us when we need it to be simple.
I've done this in two different ways:
1) unique tables per list
2) a master table for the list, with views to give specific ones
I tend to prefer the initial option as it makes updating lists easier (at least in my opinion).
Try turning the question around. Why do you need to pull it from the database? Isn't the data part of your model but you really want to persist it in the database? You could use an OR mapper like linq2sql or nhibernate (assuming you're in the .net world) or depending on the data you could store it manually in a table each - there are situations where it would make good sense to put it all in the same table but do consider this only if you feel it makes really good sense. Normally putting different data in different tables makes it a lot easier to (later) understand what is going on.
There are several approaches here.
1) Create one table per pick list. Each of the tables would have the ID and Name columns; the value that was picked by the user would be stored based on the ID of the item that was selected.
2) Create a single table with all pick lists. Columns: ID; list ID (or list type); Name. When you need to populate a list, do a query "select all items where list ID = ...". Advantage of this approach: really easy to add pick lists; disadvantage: a little more difficult to write group-by style queries (for example, give me the number of records that picked value X".
I personally prefer option 1, it seems "cleaner" to me.
You can use either a separate table for each (my preferred), or a common picklist table that has a type column you can use to filter on from your application. I'm not sure that one has a great benefit over the other generally speaking.
If you have more than 25 or so, organizationally it might be easier to use the single table solution so you don't have several picklist tables cluttering up your database.
Performance might be a hair better using separate tables for each if your lists are very long, but this is probably negligible provided your indexes and such are set up properly.
I like using separate tables so that if something changes in a picklist - it needs and additional attribute for instance - you can change just that picklist table with little effect on the rest of your schema. In the single table solution, you will either have to denormalize your picklist data, pull that picklist out into a separate table, etc. Constraints are also easier to enforce in the separate table solution.
This has served us well:
SQL> desc aux_values;
Name Type
----------------------------------------- ------------
VARIABLE_ID VARCHAR2(20)
VALUE_SEQ NUMBER
DESCRIPTION VARCHAR2(80)
INTEGER_VALUE NUMBER
CHAR_VALUE VARCHAR2(40)
FLOAT_VALUE FLOAT(126)
ACTIVE_FLAG VARCHAR2(1)
The "Variable ID" indicates the kind of data, like "Customer Status" or "Defect Code" or whatever you need. Then you have several entries, each one with the appropriate data type column filled in. So for a status, you'd have several entries with the "CHAR_VALUE" filled in.