In Spotfire I have a dashboard that uses both filtering (only one filtering scheme) and multiple markings to show the resulting data in a table.
I have created a data function which takes a column and outputs the data in the column after the active filtering scheme and markings are applied.
However, this output column is only calculated if I have something marked in every marking.
I want the output column to be calculated no matter how many of the markings are being used. Is there a way to do this?
I was thinking I could use an IronPython script to edit the data function parameters for my input column to only check the boxes for markings that are actively being used. However, I can't find how to access those parameters with IronPython.
Thanks!
I think it would be a combination of visuals being set to OR instead of AND for markings (if you have a set of markings that are being set from others).
Also are all the input parameters set to required parameter perhaps unchecking that option would still run the script. In the r script you may want to replace null values as well.
Not too sure without some example.
Related
I have a chart where I am trying to show a timeline of process logs per system. It is displaying all the logs correctly on the chart, giving a unique color to each log. I'm trying to see if I can color code the logs by specific attributes. Example: Each process log has a Cycle Type value. I'd like to have all logs with the same cycle type value to be the same color.
It seems that the "Synchronize Groups in" property under the "Series Group Properties" is where I would put the Cycle Type value in, but the combobox for that property is empty, and if I hard code the cycle type value in, the report throws an error.
So right now I'm wondering what populates the "Synchronize Groups In" combobox for Series Groups?
I could potentially hard code the series color to set the color based on the Cycle Type values, but I'm looking for something more dynamic.
There are a few ways to do this. Typically I would add a table, either a physical database table or a temporary one defined in your dataset query.
Essentially I would end up with an additional column containing my desired colour as a hex value but stored as a string, so the column might contain #3D5070 as a string. I then use an expression as the series colour, something like =Fields!myColourColumn.Value . I'm typing this from memory so you might need to wrap this in a FIRST().
I prefer this approach as you can have simple table containing either an ID, a description (or both) and the colour, then you can join this in your dataset query and re-use it in other reports, knowing you will get a consistent theme.
You can also write a VB function to do the same kind of thing, but you have to plug that into every report and it's not quite as flexible as the database approach.
There are other method to such as this one in the SSRS documentation https://learn.microsoft.com/en-us/sql/reporting-services/report-design/specify-consistent-colors-across-multiple-shape-charts-report-builder-and-ssrs?view=sql-server-ver15
I am somewhat new to MS Access and I have inherited an application with a table that uses this Lookup feature to replace a code with a value from a query to another table.
When I first used this table and exported it to Excel for analysis, I somehow got the base ID number (or whatever it would be called) rather than the translated lookup value. Now, when I do this, I get the translated text. The biggest problem is that while the base value is unique, the translated values are not, so I cannot use them for the work I am doing.
Can someone explain how to get the underlying ID value rather than the lookup value? Is there some setting I can use or some way to reference the field upon which the lookup is based. When I query the ID field, I get the lookup value. I know that the first time I did this, the spreadsheet contained the ID number not the text.
For now, I created a copy of the table and removed the lookup information from this copy, but I know I did not run into this when I did this the first time.
Thanks.
When you export to Excel, leave Export data with formatting and layout unchecked. This will create a spreadsheet with raw data values in Lookup fields.
Export settings image
I would like to use parameters in Invantive control.
For example, I would like to retrieve only the hours, of Exact Online Project management which, are in the given data parameters.
There are three often used approaches:
Use parameters in the model editor.
Use Excel values.
Use data from the databases involved.
Model Parameters
To use parameters in the model editor, you define them in the model editor:
Select a unique code.
Possibly provide a default value (always string, use to_... or casting to change it in the queries).
Define list-of-values providing a quick pick.
The unique code is in general all in uppercase and in the format P_..., but as long it is a legal identifier anything should work.
To use them in one or more block queries or triggers:
Use the building blocks button.
Or type $P{CODE} in the SQL or trigger for Excel.
The values can be entered using the parameters button (the green funnel in the Control ribbon):
Please note that parameters are always bound as parameters, and not lexicographically substituted so you can NOT say: select * from $P{TABLE_NAME}.
Please note that parameters can be dependent on each other, so in the query for the parameter you can use another parameter. Such as first choosing the country of a project and then showing a list of projects in that country. But be wise, avoid recursion and other overly complex scenarios; the user will not easily understand it.
Excel values
To use Excel values, you can define them as follows:
Enter a value somewhere in Excel.
Optionally define a named range to make it easier to change the location.
You can of course assign lists as normal in Excel as a pop-up or other validations. Also cell locking works fine.
To use the actual value in a query or trigger of Invantive Control you can use the building blocks in the query editor or use something like select * from table where code = $X{projectcode} or select * from table where code = $X{B2&C2&D2}. The last one shows that you can also use other type of Excel expressions.
Note that Excel parameters are also bound as parameters to the query, but that they are also typed, so the following query can be different depending on the general format of the Excel cell:
select *
from table
where code like $X{CELL}
When cell is a text, the database or Exact Online in this case will retrieve:
select *
from table
where code like :ex0
With ex0 being a text such as '8%'. But when cell is a percentage, the contents might still display in Excel as '8%', but the actual query will be with identical to the outcome of:
select *
from table
where code like 0.08
Caused me some headaches, but typing is in general a useful feature, especially with dates.
Parameter using database data
Option 3 is practically not feasible with Exact Online, since they are little possibilities to create your own tables and/or fields.
On other platforms such as Oracle you might want to enter new rows in Invantive Control in Excel and them upload them on sync to provide parameters. Especially handy in case of complex risk models.
I have a database built that, after all of the queries are done, it will spit out a form and I can filter through records and the relevant information will change as I filter through. To get there, I have to be able to reference a combo box located on my entry form (which contains all of the sales guys' ID numbers) in my queries. However, when I input the normal form reference in the criteria section '[Forms]![Entry Form]![ID]' and run the queries, it returns nothing. I figure that this is because in a lot of our live data tables, the ID numbers have spaces before or after them, which they have no spaces in the ID numbers listed in the combo box. I tried to use the trim function in my queries for the ID number field in the tables, but it still returned nothing.
Any advice on what else I can try? If more info is needed, ask away.
Change the Bound Column to 2, or whatever column it is in the row column, all under the property sheet data tab for combo box. It may be returning the ID rather than the text when selecting.
This is a case where the query designer isn't the best option. Instead, open it in SQL mode (there should be a dropdown in the upper left corner that allows you to change how you view the query) and change the WHERE clause to something like:
Trim(ID) = [Forms]![Entry Form]![ID]
It's not going to be very efficient, this is why you should never use bound forms because you can do the trimming on data entry and save on the overhead, but this should at least return data for you.
I figured it out!! The answer to my problem was I needed to manually type in the combo box options instead of importing the options from another table. For some reason that worked. Thanks for you guys' help again!
I am designing a form at work where I need to be able to set "Properties" for a large number of (accounting) "structures". I have a "Value" field where the user enters the value that property must take and then I have 1 column for every structure where the user must be able to check / uncheck each property for each structure. Also, I need to be able to suggest checkbox values (aka mapping of properties to structures) to the user so that he/she doesn't have to manually click all the checkboxes that will always need to be ticked. Finally, the number of properties (rows) and the number of structures (columns) should not be assumed to be fixed though I don't want the user to be able to modify it himself. I just want it so that a dev (probably me) doesn't have a hard time adding or removing structures.
For now I have used a local table where each structure is a column and I have hardcoded my properties (which is good). However, I am not sure that using a local table is good design. We normally avoid having forms and tables in the same Access DB to separate forms and data. Also, I'm wondering if there is an elegant solution that I am missing. There will be at least 10-15 structures and 11 properties, that would make 110 (11*10) checkboxes to handle so I cannot do it manually (i.e. create 110 checkboxes and check 110 values everytime...).
Here you can see what that part of the form looks like for now.
I know this will be a chattier question but I really need a design check on this so here are a few questions that I try to make as general and objective as possible:
In Access, how is it possible to create a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties, a "value" field that can take text and then 10+ columns with Yes/No values ?
Is it possible to do it without a local table ?
VBA is perfectly admissible.
Thanks.
In Access, how is it possible to create a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties, a "value" field that can take text and then 10+ columns with Yes/No values ?
I've never seen any VBA code that does what you describe. VB6 allowed the creation of "control arrays" to logically group controls (and work around some limitations on the number of controls on a form), but I've never seen that mentioned for VBA.
Is it possible to do it without a local table?
Is it possible? Maybe, since you can modify a form via code by opening it in Design View and using CreateControl() to add controls.
Is it practical? Probably not, because the "Access Specifications" section of Access Help mentions the following limit...
"Number of controls and sections that you can add over the lifetime of the form or report: 754"
..so it sounds like code that repeatedly modifies a form could very well break after a while.
My recommendation would be to create a temporary table, use it, and then discard it. If you're worried about front-end bloat then you could create the temporary table in a temporary .accdb file and then link to it.
Maybe I'm missing something, but it seems pretty easy to me.
Make each structure a record.
Then in another table, make each property a record with a 1-many relationship with the structure table. So, each structure will have many properties.
Then a form based on the structure with a sub-form based on it's properties.
Default property values can be set in the table structure.
And of course the tables can be linked from another DB.
In Access, how is it possible to create a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties, a "value" field that can take text and then 10+ columns with Yes/No values?
I'm still not certain why you want multiple bits/booleans in a single column, but you might be able to utilize bit logic and long integer column. VBA does something like this with its constants. For instance, in a MsgBox, you make your type = vbCritical + vbYesNo. Its result is in an integer value that VBA interprets to make a Critcal MsgBox with only a Yes and a No button. The reason this works is because the value of each constant is so distinct that any summation with like constants results in a unique value that can be de-parsed. It's fairly elegant from a user perspective, but I'd hate to do the math on the back-end to make such a function work.
It might be better to maintain a separate table of available properties and/or property sets and build / maintain your property sheet that way. You could assign property sets as well as individual properties to particular controls. You could also specify in either table whether there is a default value for that property and/or what that value is.
It is also likely that you do not need that many bits. I'd be happy to narrow my answer to your situation if you could update your question with more detail regarding the nature of your bit need(s).
Is it possible to do it without a local table?
You might be able to create a DAO.Recordset dynamically in Access.
It might be better to adjust your properties table(s) (see above) to be a permanent table in one of your databases rather than re-populating the same data every time.
You could take more of a master/detail approach, combining your bit fields into a string description describing the boxes which are checked.
For example, if you have a structure named 'structure1', value 100, and 5 condition bits set, you could have one string column with text 'cond1, cond2, cond7, cond8, cond9' and then another button allowing them to modify that set of conditions for that single structure.
You'd have fewer checkboxes, anyways.
The only thing I can think of equivalent to 'a matrix of controls where 1 column contains a fixed (but changeable by a dev) number of properties' is an editable query result set.
You'll need a table for your structure -> default conditions set, if nothing else, but it doesn't have to be in the same db as the front end.
HTH