![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/Filter.png\")
Opens the popup dialog box allowing you to edit the properties of this where filter line, described in more detail above.
The Query Runner Parameters view is used to create all the parameters that can be used by each query runner step as parameters they can pass to their process.
\n", "content_html": "The Query Runner Parameters view is used to create all the parameters that can be used by each query runner step as parameters they can pass to their process.
\n\nAll Query Runners, automatically have the parameters of the SQL Wrapper they are associated with. Each Query Runner Step can use the row results of that SQL Wrapper as parameters for their process.
\nHowever sometimes parameters you use to run a query don't make sense in the final result set, or aren't easily included there. Query Runner Parameters allow you to create additional parameters for running the Query Runner, that are accessible for every Query Runner Step. These values won't change for every row result of the SQL Wrapper, and are instead global parameter values for that Query Runner that can be used as parameters for every Query Runner Step.
\nQuery Runners also provide two special parameters that are accessible to Query Runner Steps. They are the following:
\n| Name | \nDescription | \n
| @runKey | \nThe unique run key for that instance of the Query Runner execution. Each run produces a unique key that query runner steps have access to as a parameter they can use. | \n
| @rowResultNumber | \nHolds the current number of the row result from the Query Runner SQL Wrapper that is being used to execute the Query Runner Step | \n
By default the system produces the @runKey value, but you can create your own parameter named @runKey and the system will always use that. This allows you to provide the same value every time (instead of the unique one the system does), or re-use a prior one, for debugging/testing purposes.
@runKey is useful for complex queries that are run hundreds of times by each step (as the main SQL Wrapper returns hundreds of rows). Instead your report could run a stored procedure that if the rownumber is 1, it runs the whole query and temporarily stores the data using the @runKey, then returns the results filtered for its parameter. Then when the stored procedure runs for the 2nd row number, it can see the @runKey results already exist and can just select with its parameter values. This can significantly speed up queries that take a long time to re-run for different parameters versus running once with no parameter.
The parameters for your Query Runner have the same functionality as SQL Wrapper Parameters [see here]. Specifically for Query Runners they have the following properties:
\n| Name | \nDescription | \n
| [Required] Name | \nThe user friendly name for this parameter | \n
| Description | \nA user friendly description for this parameter that is shown as a tooltip to the user | \n
| SQLType | \nThe underlying sql type for this parameter in the function or procedure it writes for you. This should match the underlying sql type of the field itself if you are mapping it to one. i.e. if this holds an ID to a record then it should be of type uniqueidentifier. | \n
| IsNullable | \nIndicates if the field can be left blank with no input from the user | \n
| Max Length | \nIf the field is a type of text field (nvarchar, etc) this indicates the max length for that field. Leaving this blank would be the equivalent of varchar(max) - presumably unnecessary for a text input parameter though. | \n
| Precision | \nIf this field is a decimal this holds the precision value. i.e decimal(16,8) | \n
| Scale | \nIf this field is a decimal this holds the scale value. i.e. decimale(16,8) | \n
| Visible | \nIndicates if this parameter should be visible to the user. By default some system parameters are not visible, such as those for permissions. This gives you the ability to make a field invisible and auto populate the value through formulas. | \n
| EntityType | \nIf this field maps to a field in the system you can specify the entity type of that field here. Doing so will mean the system will understand automatically how to display a control for this parameter. For instance if you select Tasks as Entity Type and ID as Entity Property Name, the system will provide a popup of all available tasks for this parameter. | \n
| Entity Property Name | \nThe property this field maps to within the selected EntityType. | \n
| Format | \nApplies any formatting to the display of this control. [see here for more info] | \n
| [Required] [Key] Param Name | \nThe unique parameter name. Must begin with an '@' symbol. | \n
| Required | \nIndicates if the user must enter a value for this parameter | \n
| Default Value | \nProvides a hardcoded default value for this parameter | \n
| Formula Value | \nProvides a formula that can be run at execution time to determine a default value for this parameter | \n
A Query Runner Parameter has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
", "author": { "name": "Gareth" }, "tags": [ "UI - Views", "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-30T19:32:41+00:00", "date_modified": "2021-01-31T15:51:26+00:00" }, { "id": "https://web.lemonedge.com/help/venn-set-where-filters/", "url": "https://web.lemonedge.com/help/venn-set-where-filters/", "title": "Where Filters View", "summary": "Venn Set Where Filters allow you to create a hierarchical where filter to apply to your Queryable Item to ensure you get only the results you require as efficiently as possible. These filters can apply against the Venn Set parameters, and against any field for that queryable item your filtering in the query.
\n", "content_html": "Venn Set Where Filters allow you to create a hierarchical where filter to apply to your Queryable Item to ensure you get only the results you require as efficiently as possible. These filters can apply against the Venn Set parameters, and against any field for that queryable item your filtering in the query.
\n\nThe where filter allows you to create a hierarchical filter for your query that can ensure you only get the results you require. The filter allows you to specify that any property of Queryable Items should match one the following:
\nThe where filter can be edited using our standard TreeView controls [see here for more info].
\nWhere Filters are specific to the currently selected Venn Set Queryable Item. You can not have refer to multiple Queryable Items in a single Where Filter like you can in Datasets. This is because a where filter in a dataset applies to the whole query, whereas for a Venn Set it is specific to each Queryable Item. You are filtering the data before the Venn Set merges each Queryable Item data together into one cohesive set of results.
\nWhenever you create a new where filter the system automatically pops up a dialog box allowing you to configure the properties of the where filter line. The properties are as follows:
\n| Name | \nDescription | \n
| [Required] Composite Operator | \n\n Indicates if this is an actual comparison filter, or a logical composite operator that has children filters. Can be: \n
| \n
| Source Property Entity | \nThe Queryable Item you want to apply a filter to. This is read-only and is always the selected Queryable Item. | \n
| Source Property | \nThe property of the Queryable Item you want to apply a filter property to | \n
| Operator | \n\n The operator used to compare the source property against the value with. Can be: \n
| \n
| Compare To Hardcoded Value | \nA hardcoded value to compare the Queryable Item Property to using the comparison Operator. | \n
| Compare To Parameter | \nIndicates the Queryable Item Property should be compared to the specified global parameter of the Dataset using the comparison Operator. | \n
| Compare To Entity | \nIndicates a Queryable Item to use in the comparison against the Source Property - Can only be the currently selected Queryable Item. You can not refer to other queryable items in a Venn Set where filter, it is specific to the current selected one. | \n
| Compare To Entity Property | \nIndicates the property of the Queryable Item to use in the comparison against the Source Entity Property using the comparison Operator | \n
| Wrap Comparator In Is Null | \nIndicates the Source Property of this filter should be wrapped in an IsNull clause to match the specified value if null. | \n
The system displays your where filter in an easily intuitive display within the tree view. For instance the following where filters:
\nComparative Operator: And
Filter: User.ID = UserRole.UserID
Filter: Role.ID = UserRole.RoleID
Would show as:
\nAnd
User.ID = UserRole.UserID
Role.ID = UserRole.RoleID
And would be translated in to the following SQL (roughly):
\n(User.ID = UserRole.UserID And Role.ID = UserRole.RoleID)
\nA Where Filter View has the standard set of commands and functions when being viewed from a tree view. See our standard tree view functionality.
\nWhere filters also have the following custom commands:
\nThe Venn Set view enables you to view and edit basic information about an overall Venn Set. Venn Sets are used to combine multiple queries of the same shape into one merged dataset. Each Venn Set creates an underlying SQL Wrapper [see here] for retrieving the data and interacting with it throughout the LemonEdge platform.
\n", "content_html": "The Venn Set view enables you to view and edit basic information about an overall Venn Set. Venn Sets are used to combine multiple queries of the same shape into one merged dataset. Each Venn Set creates an underlying SQL Wrapper [see here] for retrieving the data and interacting with it throughout the LemonEdge platform.
\n\nVenn Sets enable you to merge multiple queries together in an easy and intuitive manner. Venn Sets can query all entities and all their fields, along with all associated permissions and history, and even includes the ability to query any underlying SQL Wrapper, allowing Venn Sets to merge other Venn Sets too.
\nThis last feature allows you to easily build up a standard library of SQL Wrappers, using Datasets, that any user can then easily incorporate in to a Venn Set without having to expose them to any of the underlying working of your data structure. They can simply merge datasets together to see the data the way they wish to.
\nEach Venn Set is responsible for creating a single set of data in the shape you require, and ensuring all data being merged into this single set conforms to the same shape. This combined single set of data is accessible through a SQL Wrapper the Venn Set is responsible for automatically maintaining. This allows you visibility into how everything is being designed for your query, but also to utilise the deep integration into the platform SQL Wrappers allow - including combining your Venn Set with custom sql wrappers.
\nVenn Sets are not responsible for creating data in any format you require. Rather they are responsible for merging existing sets together. You can use SQL Wrappers, or Datasets to create underlying queries of data in any way you like that you can then combine together using Venn Sets.
\nVenn Sets have the following top level properties:
\n| Name | \nDescription | \n
| [Required] [Key] Name | \nThe unique user friendly name for this venn set | \n
| [Required] [ReadOnly] [Automatically Maintained] SQL Wrapper | \n\n The link to the SQL Wrapper that allows you to execute this venn set, and otherwise interact with it throughout the whole LemonEdge platform. | \n
| Description | \nA user friendly description of this venn set | \n
A Venn Set has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
\nVenn Sets can be exported and imported as packaged xml files to transfer configuration across systems. The export includes the SQL Wrapper, and any other Venn Sets/Data Sets/SQL Wrappers that are referenced within it, all protected using our standard versioning. Again this is available from the standards grid commands.
\nVenn Sets also have the following custom commands:
\n![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/PublicPrivate.png\")
![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/Excel.png\")
![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/Properties.png\")
By default all Datasets, Venn Sets, and SQL Wrappers, in the system have the following set of system parameters:
\nThe parameters for your Venn Set have the same functionality as SQL Wrapper Parameters [see here]. Specifically for Venn Sets they have the following properties:
\n| Name | \nDescription | \n
| [Required] Name | \nThe user friendly name for this parameter | \n
| Description | \nA user friendly description for this parameter that is shown as a tooltip to the user | \n
| SQLType | \nThe underlying sql type for this parameter in the function or procedure it writes for you. This should match the underlying sql type of the field itself if you are mapping it to one. i.e. if this holds an ID to a record then it should be of type uniqueidentifier. | \n
| IsNullable | \nIndicates if the field can be left blank with no input from the user | \n
| Max Length | \nIf the field is a type of text field (nvarchar, etc) this indicates the max length for that field. Leaving this blank would be the equivalent of varchar(max) - presumably unnecessary for a text input parameter though. | \n
| Precision | \nIf this field is a decimal this holds the precision value. i.e decimal(16,8) | \n
| Scale | \nIf this field is a decimal this holds the scale value. i.e. decimale(16,8) | \n
| Visible | \nIndicates if this parameter should be visible to the user. By default some system parameters are not visible, such as those for permissions. This gives you the ability to make a field invisible and auto populate the value through formulas. | \n
| EntityType | \nIf this field maps to a field in the system you can specify the entity type of that field here. Doing so will mean the system will understand automatically how to display a control for this parameter. For instance if you select Tasks as Entity Type and ID as Entity Property Name, the system will provide a popup of all available tasks for this parameter. | \n
| Entity Property Name | \nThe property this field maps to within the selected EntityType. | \n
| Format | \nApplies any formatting to the display of this control. [see here for more info] | \n
| [Required] [Key] Param Name | \nThe unique parameter name. Must begin with an '@' symbol. | \n
| Required | \nIndicates if the user must enter a value for this parameter | \n
| Default Value | \nProvides a hardcoded default value for this parameter | \n
| Formula Value | \nProvides a formula that can be run at execution time to determine a default value for this parameter | \n
This is displayed in a popup grid to the user, and has all the standard commands available to all standard grids including the ability to move the parameters up/down in order.
\nNote: The standard default parameters should always remain at the top in the system order of Account, Canvas, Team, As Of Date.
", "author": { "name": "Gareth" }, "tags": [ "UI - Views", "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-26T21:31:39+00:00", "date_modified": "2021-01-28T11:57:15+00:00" }, { "id": "https://web.lemonedge.com/help/venn-set-queryable-items-view/", "url": "https://web.lemonedge.com/help/venn-set-queryable-items-view/", "title": "Queryable Items View", "summary": "Venn Set Queryable Items allow you to specify multiple sets of data you want to merge into one cohesive result set. The sets of data you can include in a Venn Set come from 2 main sources; Entities, History, and Queries themselves. The last one allowing you to include other Venn Sets themselves within a venn set.
\n", "content_html": "Venn Set Queryable Items allow you to specify multiple sets of data you want to merge into one cohesive result set. The sets of data you can include in a Venn Set come from 2 main sources; Entities, History, and Queries themselves. The last one allowing you to include other Venn Sets themselves within a venn set.
\n\nThe items you can query in a Venn Set are represented here in a list that easily shows at a glance all the sets of data that you are merging into one set. This also includes how the items are merged together by the type of merge operator. The items you can query come from the following main sources:
\nBeing able to query SQL Wrappers (which every Dataset and Venn Set creates one of anyway to retrieve their data [see here for more info]) allows you to easily build up a library of re-usable queries. These can be used by any user to get results but also to query themselves without having to understand any of your underlying data structure.
\nVenn Sets are responsible for creating a single set of data by combining multiple set of data together. These multiple set must all have the same structure in order to be merged together correctly. Each queryable item can be filtered, but if you want to create complex data sets to be included in a Venn Sett, it is best to create the complex query first as a Dataset and then to simply include that in the Venn Set itself.
\nWhenever you create a Venn Set Queryable Item the system pops up a dialog box allowing you to choose the properties of the item you want to query. This has the following properties:
\n| Name | \nDescription | \n
| [Required] Queryable Item Type | \nThe type of item you want to query. This can be an Entity, History, or Query. | \n
| Queryable Item | \nThe item of the specified type that you want to query | \n
| Queryable Item Option | \nSome Queryable Items contain sub options. Permissions is an example of this. If you select a Permission item to query of the Entity type, this will display a set of options for which entity type permission you want to query | \n
| [Required] Name | \nThis is the user friendly name of the queryable item as it will appear in the list of Venn Set Queryable Items. | \n
| Set Operator | \n\n If this Queryable Item comes after any other in the list, then this specifies the operation to be used to merge this and the prior item data together: \n
| \n
You can always edit these properties for any Queryable Item by selecting the
Whenever you create a new Queryable Item the system allows you the ability to pass parameters to that queryable item from the main parameters defined against the Venn Set itself [see here].
\nYou can always click on the ![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/Attachment.png\")
| Name | \nDescription | \n
| [Required] Source Queryable Item Field | \nA parameter within the global parameters for the Venn Set itself. | \n
| [Required] Target Queryable Item Field | \nThis is the property on the selected queryable item that you want to use to join to the global parameter value. This will list all fields against this queryable item, and if it has parameters (is a query queryable item) those will also be listed allowing you to pass values into the parameters as part of the join. | \n
You can add as many parameter joins as you require here, to pass as many global parameters from the Ven Set to the queryable item as you require.
\nA Venn Set Queryable Item has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
\nQueryable Items also have the following custom commands:
\n", "author": { "name": "Gareth" }, "tags": [ "UI - Views", "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-26T21:14:13+00:00", "date_modified": "2021-01-28T14:55:22+00:00" }, { "id": "https://web.lemonedge.com/help/venn-set-sql-type-wrappers/", "url": "https://web.lemonedge.com/help/venn-set-sql-type-wrappers/", "title": "Columns View", "summary": "
The Venn Set Column view allows you to specify precisely which columns you would like returned in your Venn Set for each of the individual Queryable Items to be merged in the Venn Set. This allows you to ensure each Queryable Item has the same data structure, before being merged, in an intuitive and easy to follow way.
\n", "content_html": "The Venn Set Column view allows you to specify precisely which columns you would like returned in your Venn Set for each of the individual Queryable Items to be merged in the Venn Set. This allows you to ensure each Queryable Item has the same data structure, before being merged, in an intuitive and easy to follow way.
\n\nThe columns displayed here are the actual columns that will be returned by your resulting query. Each Queryable Item must have the same number, and type, of columns defined so the overall merged set of data all conform to the same shape.
\nColumns are defined against the currently selected Queryable Item, and the column defined for the first Queryable Item dictate the columns, and type, that all other Queryable Items in this Venn Set must also have. For instance if you have the Users entity and the Teams entity in a Venn Set, and want to merge them in to a combined list of user and team names, then you would add the Name from the User entity as a column first. You would then need to add the Name for the Team entity as a column too, so both entities have the same columns being returned and can be merged together.
\nThe columns specified for the first Queryable Item here are directly the columns that will be visible in the SQL Wrapper itself [see here for more info]. This is because by definition all the other Queryable Items must have the same number, and type, of columns defined too in order for the data to be combined correctly.
All of these columns then construct the shape of the data returned by this Venn Set. Most importantly the system completely understands all aspects of the parameters, query and return columns so the venn set can be completely integrated into the platform as if it's a standard created view.
It's important to note that the names provided by the first Queryable Item will be the names returned by the actual SQL Wrapper itself when executing this query. The other Queryable Items may have the same columns and structure, but may also have different names. The names defined on those columns are ignored as only the ones used from the first Queryable Item are used, as all the data is merged into one set anyway.
\nColumns can also have column properties, behaviour properties (such as aggregate options), and grid display properties.
\nYou can also create custom calculation columns that perform custom sql you want embedded in the calculation.
\nWhenever you have a Queryable Item selected you will be able to use the \"New SQL Type Wrapper\" command to add fields from that QueryableItem to the columns of this venn set.
\nWhen you click the command (only available if you have a Queryable Item selected) the system will popup a dialog box listing all the available fields within that Queryable Item. You can multi-select as many fields as you would like to add and hit Ok. The system will automatically add all those fields as columns to the venn set in the correct order.
\nIt will also automatically configure the columns to have the correct type, and settings, depending on what the field you added is. For instance it will set up the Name, Entity Type, Entity Property Name, Enum Property Name, SQL Type and other properties for you.
\nThis makes it incredibly easy to just add the fields you want from the QueryableItems you have selected into the set of column results.
\nYou can also create custom calculation fields. To do this you can select ![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/Function.png\")
This will create a new column that doesn't have fields auto-populated. You will need to specify the name, any entity type/property relationships, and the SQL Type (defaults to nvarchar(50)).
\nYou can then select the
You can refer to any other column in your sql using the format {ColumnName}. So for instance if you have two columns called TotalA and TotalB you can create a custom sql calculation field with the sql being:
IsNull({TotalA}, 0.0) + IsNull({TotalB}, 0.0)
Which will sum both columns together to give you a grand total.
You can also refer to any custom SQL Functions (such as the system standard IRR calc) in the calculation. As this is an aggregate calculation you also need to select \"Has Custom Aggregate\" for the column and the system will automatically group the result by all other non-aggregated columns.
You must make sure that the sql you enter has a return type that matches the type you specified for the column itself. If it doesn't your venn set will fail to return results and will throw an error.
\nIt's important to note that this functionality is also restricted and certain keywords if used (such as 'drop', etc) will result in an error and the venn set will fail to run. You should restrict this functionality to only the root account with the correct permissions.
\nThe columns of a venn set, are the same as the columns of a SQL Wrapper [see here for more info], and have the following properties:
\n| Name | \nDescription | \n
| [Unique] [Required] Name | \nThe name of this column. This is the name used as column headers in csv exports, and is the mnemonic you can use to refer to this columns value in custom sql formulas. | \n
| Column User Friendly Label | \nThis is the column name the user sees when the results are displayed in a grid, or other presentation format. | \n
| [Key] Index | \nThe order this column will appear in the result set. This can be moved up and down using the standard grid commands. | \n
| Parent Index | \nThis column is hidden by default but can be made visible to edit if needed. The parent index is used for columns that display labels for unique identifiers. If you have a column that holds a unique identifier key, you can set the label of that column to have a parent index of the uniqueidentifier column. The system will then know how to display the label in the grid for the user rather than a list of uniqueidentifiers the user won't be able to recognize. | \n
| Description | \nA user friendly description of this column | \n
| Visible | \nIndicates if this column is visible by default when the results are displayed in a grid. The user can always make the column visible if it is hidden, and will always see the column in result exports too. | \n
| Exclude From Result Set | \nIndicates this column is not actually to be included in the result set. Can be used to refer to the column itself in custom calculations but make sure it isn't included in the actual results as a column itself. | \n
| Aggregate | \n\n Indicates this column should have its results aggregated. Can be: \n
If this is anything but None, then all other columns that have an aggregate of None will be used as part of the Group By for the result set. \n | \n
| Has Custom Aggregate | \nIndicates this column has a custom calculation that applies a custom sql clr aggregate function to the results. Use the Edit Calculated Field command to edit the custom calculation to call your clr sql aggregate function. This refers to SQL Functions (which define the clr sql functions that can be used) and is only available as an option if the AllowCLRSQLFunctions flag in the GlobalEnv table is set to 1. All other non-aggregated columns will be set to group by in the result set just as they would if an Aggregate value other than None had been selected. | \n
| EntityType | \nThe type of entity this column has data that originates from. | \n
| Entity Property Name | \nThe property of the Queryable Item that this column is populated from | \n
| Enum Property Type | \nIf this property is an enum type this holds the type of enum to be used for displaying in grids. | \n
| Format | \nApplies any custom formatting you want to the result when displayed in a grid. See here for more info. | \n
| Footer Aggregate | \nIndicates when displayed in a grid that this column should be totaled automatically and displayed on the grid itself. This will also happen when the data is arbitrarily grouped by the user. | \n
| Group Header | \nIndicates this column should belong to a header group when displayed in a grid | \n
| Sub Group Header | \nIndicates this column should belong to a sub header group within a group header when displayed in a grid | \n
| Group By | \nWhen displayed in a grid this indicates this column should automatically be grouped in the grid | \n
| Freeze Up To | \nBy default the first column is frozen when displayed in a grid. Here you can specify a different column that should be frozen when scrolling through the grid horizontally. | \n
| Part Of Row Header | \nWhen scrolling vertically the scroll bar displays a row header quick view. This indicates if this column should be part of that template. | \n
| Is Default Search | \nIndicates when the user searches the grid that this column should be included in that search by default | \n
| SQL Type | \nIndicates the actual underlying sql type this column holds | \n
| Max Length | \nThe max length to use if this column is a text type such as nvarchar. If blank it is the equivalent to nvarchar(max). | \n
| Precision | \nIf this is a decimal sql type this holds the precision amount as in decimal(18,2) | \n
| Scale | \nIf this is a decimal sql type this holds the scale amount as in decimal(18,2) | \n
A Column has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
\nAs a Column has a sequence the standard grid allows you to move the items up and down changing their order.
\nThe Column grid also has the following custom commands:
\nVenn Sets allow you to combine multiple queries together into one query, through set operators such as union, intersect and except. Like Datasets, this also automatically creates an underlying SQL Wrapper for the resulting query that can be incorporated and called throughout the LemonEdge platform.
\n", "content_html": "Venn Sets allow you to combine multiple queries together into one query, through set operators such as union, intersect and except. Like Datasets, this also automatically creates an underlying SQL Wrapper for the resulting query that can be incorporated and called throughout the LemonEdge platform.
\n\nVenn Sets are designed to allow you to merge multiple disparate data sets together into one cohesive result set. This works with data that is related and needs to be combined in a cohesive form. Data that has completely different structure is best kept as multiple different datasets that can be executed together with Query Runners where each different result set can be opened as a separate sheet in excel.
\nVenn Sets can combine any data set from the following sources:
\nThe multiple sources of data can be combined using unions, intersections, and exception set aggregation methods.
\nWhen you've designed a Venn Set the system actually creates an underlying SQL Wrapper (which you have access to and can open/view) for you that holds the query the system will run against the database. See here for more information on SQL Wrappers.
\nAll Venn Sets automatically have permissions enforced throughout them and can not be bypassed
\nEqually all Venn Sets have canvas technology baked into them so they automatically tun correctly across any canvas you are using.
\nVenn Sets automatically write a SQL Wrapper as SQL Wrappers are the core module for internal reporting throughout LemonEdge. SQL Wrapper results can automatically be incorporated into every part of the LemonEdge platform - whether they were created by the system automatically (for example through VennSets/Datasets), or hand crafted by yourselves in SQL. Either way they can be fully integrated into the platform. For example whether a SQL Wrapper was created by a Venn Set or not, it is still available in the set of items that a Dataset or VennSet can query.
\nBy using the Venn Set query tool rather than hand crafting your SQL you gain the following benefits:
\nVenn Sets, as with SQL Wrappers, are automatically versioned. Any system provided venn set will automatically upgrade on new versions. Also you can export/import venn sets across systems safe with the knowledge you won't overwrite newer versions.
\nCreating a Venn Set is as easy as choosing the multiple sources of data, how you want to combine them, and making sure they all return the same data structure so they can be combined into one set. If you don't yet have data in the shape you want to combine with other sets of data yet, you can use the Datasets query tool to create as many sets of data as you require. You can then use Venn Sets to combine these together according to your requirements.
\nVenn Sets let you add Queryable Items together into one set of data. A Queryable Item can be one of the following:
\nYou can then add as many fields from every Queryable Item as you like into the Column list of the Venn Set for that item. These are the results for that item that are to be merged with the results (of the same structure) of other Queryable Items in the Venn Set. You can also add custom calculation fields to perform your own calculations, including accessing our SQL Functions for custom IRR, or other, metrics. Each set of data can also be filtered however you like before merging with other sets of data in the Venn Set for the final combined result.
\nVenn Sets allow you to add custom parameters to the query, which the system will automatically prompt the user for. You can also filter any of the Queryable Item sets by creating as many hierarchical filter criteria as you like. These filters can refer to any field, value or hard coded value you like, not just the fields you've added to the result set.
\nImportantly. this easily allows you to create combined sets of data that get to the overall picture the way you want in a way that can filter the data to precisely what you need and automatically provide the correct set of parameters to the user.
\nVenn Sets automatically create and write a SQL Wrapper for you. This allows you to easily see the SQL the system is generating in a human readable format. The core reason Venn Sets do this is because SQL Wrappers are integrated into the core of the LemonEdge platform. For instance they can automatically be dragged+dropped as grids into any layout and made context sensitive to run specifically for that layout they are running in. There is a huge amount of functionality centered around SQL Wrappers such as Excel exports, Reporting, Charts, Pivots, etc. See here for more info.
\nShould you ever need to manually tweak queries you can do that by copying the SQL Wrapper itself and manually making those changes in SQL. The new SQL Wrapper will hold all of your changes and enable them to be used seamlessly in the application itself.
\nTo run a Venn Set and see the results you simply need only run the SQL Wrapper the system as generated for you. Equally you can take advantage of all the SQL Wrapper functionality and display the venn set as a context sensitive grid for KPI's, or as a chart/pivot or include it in exports, reports, or even other venn sets.
\nVenn Sets are managed using the following views:
\n\n", "author": { "name": "Gareth" }, "tags": [ "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-26T21:07:47+00:00", "date_modified": "2021-01-30T20:47:01+00:00" }, { "id": "https://web.lemonedge.com/help/report-parameters-view/", "url": "https://web.lemonedge.com/help/report-parameters-view/", "title": "Report Parameters View", "summary": "
The Report Parameters view is used to create all the parameters that must be passed to the 3rd party report in order to execute it and produce a report output file.
\n", "content_html": "The Report Parameters view is used to create all the parameters that must be passed to the 3rd party report in order to execute it and produce a report output file.
\n\nAlmost all reports you run that are based on data, or queries, from the LemonEdge platform are going to require some parameters to be passed to the report. This parameter setup screen allows you to create those parameters, allow them to be visible (or not) for selection to the user before running the report, or provide default values/formulas for them.
\nThis ensures you get a LemonEdge setup screen to correctly select values that are passed as parameters to the report service to correctly execute the report, providing a seamless experience for the user.
\nIf you are basing your report on any query created from our reporting suite, then they are likely to require the following standard parameters as a minimum:
\nThe system also has the following special report parameter values, that should be hidden as they are always automatically provided a value from the system, you can't specify it:
\n| @databaseName | \nThe current name of the connected database | \nThe name of the database the user is connected to. Can never be changed, the system will always provide the value if this parameter is configured in the report. | \n
| @databaseServer | \nThe current name of the connected sql server instance | \nThe name of the sql server instance the user is connected to. Can never be changed, the system will always provide the value if this parameter is configured in the report. | \n
The parameters for your Report have the same functionality as SQL Wrapper Parameters [see here]. Specifically for Reports they have the following properties:
\n| Name | \nDescription | \n
| [Required] Name | \nThe user friendly name for this parameter | \n
| Description | \nA user friendly description for this parameter that is shown as a tooltip to the user | \n
| SQLType | \nThe underlying sql type for this parameter in the function or procedure it writes for you. This should match the underlying sql type of the field itself if you are mapping it to one. i.e. if this holds an ID to a record then it should be of type uniqueidentifier. | \n
| IsNullable | \nIndicates if the field can be left blank with no input from the user | \n
| Max Length | \nIf the field is a type of text field (nvarchar, etc) this indicates the max length for that field. Leaving this blank would be the equivalent of varchar(max) - presumably unnecessary for a text input parameter though. | \n
| Precision | \nIf this field is a decimal this holds the precision value. i.e decimal(16,8) | \n
| Scale | \nIf this field is a decimal this holds the scale value. i.e. decimale(16,8) | \n
| Visible | \nIndicates if this parameter should be visible to the user. By default some system parameters are not visible, such as those for permissions. This gives you the ability to make a field invisible and auto populate the value through formulas. | \n
| EntityType | \nIf this field maps to a field in the system you can specify the entity type of that field here. Doing so will mean the system will understand automatically how to display a control for this parameter. For instance if you select Tasks as Entity Type and ID as Entity Property Name, the system will provide a popup of all available tasks for this parameter. | \n
| Entity Property Name | \nThe property this field maps to within the selected EntityType. | \n
| Format | \nApplies any formatting to the display of this control. [see here for more info] | \n
| [Required] [Key] Param Name | \nThe unique parameter name. Must begin with an '@' symbol. | \n
| Required | \nIndicates if the user must enter a value for this parameter | \n
| Default Value | \nProvides a hardcoded default value for this parameter | \n
| Formula Value | \nProvides a formula that can be run at execution time to determine a default value for this parameter | \n
A Report has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
\n", "author": { "name": "Gareth" }, "tags": [ "UI - Views", "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-24T01:17:34+00:00", "date_modified": "2021-01-30T16:46:15+00:00" }, { "id": "https://web.lemonedge.com/help/ssrs-report-view/", "url": "https://web.lemonedge.com/help/ssrs-report-view/", "title": "SSRS Report View", "summary": "
The SSRS Report view enables you to view and edit all the information required for connecting to, and executing, a SSRS report.
\n", "content_html": "The SSRS Report view enables you to view and edit all the information required for connecting to, and executing, a SSRS report.
\n\nThe main function of the SSRS Report view is to allow the specification of the report you want to execute on your SSRS reporting service, along with the type of report you would like to create.
\nBy default the system will connect using the SSRS credentials set up in your settings.config file (see here for more information). This uses the following settings:
\n| Name | \nDescription | \n
| \n \n \nSSRS_URL \n | \nIndicates the url to connect to your SSRS report server that the SSRS Reports will use by default. The url needs to connect to the 2005 report execution server, for example: http://localhost:80/ReportServer/ReportExecution2005.asmx?wsdl | \n
| \n \n \nSSRS_Credential_Domain \n | \nThe domain to use when using domain/username/password credentials to connect to the SSRS report server. | \n
| \n \n \nSSRS_Credential_UserName \n | \nThe username to use when using domain/username/password credentials to connect to the SSRS report server. | \n
| \n \n \nSSRS_Credential_Password \n | \nThe password to use when using domain/username/password credentials to connect to the SSRS report server. | \n
| \n \n \nSSRS_Credential_UseDefault \n | \nIndicates when connecting to the SSRS report server if it should use default network credentials or not. You must provide domain/username/password if this is false. | \n
You can however override these settings, or specifically supply them if they are not configured in your config file, for any individual report.
\nSSRS Reports have the following properties:
\n| Name | \nDescription | \n
| [Required] [Key] Name | \nThe unique user friendly name of this Report | \n
| Default Export Type | \n\n The type of file to generate when executing this report. Can be any of the following: \n
| \n
| Folder Path | \nThe path of the folder within the connected SSRS instance that contains the report you want to execute. | \n
| Report Name | \nThe name of the SSRS report you want to execute. | \n
| Override Report Server URL | \nThe override value for the SSRS_URL setting specified above | \n
| Override Report Server Domain | \nThe override value for the SSRS_Credential_Domain setting specified above | \n
| Override Report Server User Name | \nThe override value for the SSRS_Credential_UserName setting specified above | \n
| Override Report Server Password | \nThe override value for the SSRS_Credential_Password setting specified above | \n
| Override Report Server Use Default | \nThe override value for the SSRS_Credential_UseDefault setting specified above | \n
| Description | \nA user friendly description of this Report | \n
SSRS Reports also have the following custom commands:
\n![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/ServerProcess.png\")
", "author": { "name": "Gareth" }, "tags": [ "UI - Views", "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-24T01:17:19+00:00", "date_modified": "2021-01-30T18:46:36+00:00" }, { "id": "https://web.lemonedge.com/help/reports-view/", "url": "https://web.lemonedge.com/help/reports-view/", "title": "Reports View", "summary": "
The Report view enables you to view and edit basic information about any Report, regardless of the custom type of 3rd party reporting services it may connect to. Reports are used to reach 3rd party reporting services and connect to them to call and execute custom reports passing any relevant parameters from the system.
\n", "content_html": "The Report view enables you to view and edit basic information about any Report, regardless of the custom type of 3rd party reporting services it may connect to. Reports are used to reach 3rd party reporting services and connect to them to call and execute custom reports passing any relevant parameters from the system.
\n\nReports are used to call 3rd party reporting services and execute your custom report and download the generated file.
\nA key component of them is that you can define the parameters for the report and the system automatically generates a parameter selection screen ensuring users can simply select whatever they need, and the report will be run with those selections.
\nBy integrating this into our Reporting functionality we can ensure users have an integrated and seamless experience with generating reports from the system.
\nBy using our query tools (such as Datasets, GL Rollups, and Venn Sets) we can ensure that when you create these reports, it doesn't matter what 3rd party reporting tool you use as they will all be able to attach to the created query as a data source.
This guarantees you can easily design your custom reports using whatever 3rd party reporting service you prefer, while also being able to completely run them from that environment too.
Reports have the following top level properties:
\n| Name | \nDescription | \n
| [Required] [Key] Name | \nThe unique user friendly name of this Report | \n
| Description | \nA user friendly description of this Report | \n
Custom report types all have their own connection settings, and other properties in order to connect to the 3rd party reporting service. When you create a new Report, you are initially presented with a drop down list to select the type of report you want to create. The valid types, with their associated report specific views, are as follows:
\nA Report has the standard set of commands and functions when being viewed from a grid. See our standard grid functionality.
\nWhen you create a new Report, you are initially presented with a drop down list to select the type of report you want to create.
\nReports can be exported and imported as packaged xml files to transfer configuration across systems. The export includes report and its parameters and are all protected using our standard versioning. Again this is available from the standards grid commands.
\nReports also have the following custom commands:
\n", "author": { "name": "Gareth" }, "tags": [ "UI - Views", "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-24T01:16:42+00:00", "date_modified": "2021-01-29T15:57:18+00:00" }, { "id": "https://web.lemonedge.com/help/ssrs-reports/", "url": "https://web.lemonedge.com/help/ssrs-reports/", "title": "SSRS Reports", "summary": "
SSRS Reports are a type of Report that connect to SQL Server Reporting Services to execute any pre-built report.
\n", "content_html": "SSRS Reports are a type of Report that connect to SQL Server Reporting Services to execute any pre-built report.
\n\nSSRS inherit all the functionality, properties, and features of the base reporting functionality (see here), while also having a type of SSRS Report which can connect to the 2005 report execution service, typically located at http://YOURSERVER:80/ReportServer/ReportExecution2005.asmx?wsdl from your SSRS installation.
\nYou can download Microsoft SQL Server 2019 Reporting Services from the following link:
Microsoft Download Center - Microsoft SQL Server 2019 Reporting
To install and configure SSRS on your servers, you can follow this guide:
Microsoft Docs - Install SQL Server Reporting Services (SSRS)
Once you have SSRS installed, you can begin designing reports using the SSRS Report Builder, which you can download from the following link:
Microsoft Download Center - Microsoft Report Builder
To install and configure Microsoft Report Builder, you can follow this guide:
Microsoft Docs - Install SQL Server Report Services (SSRS) Report Builder
You can configure your SSRS connection information using the following settings in your settings.config file (see here for more information):
\n| Name | \nDescription | \n
| \n \n \nSSRS_URL \n | \nIndicates the url to connect to your SSRS report server that the SSRS Reports will use by default. The url needs to connect to the 2005 report execution server, for example: http://localhost:80/ReportServer/ReportExecution2005.asmx?wsdl | \n
| \n \n \nSSRS_Credential_Domain \n | \nThe domain to use when using domain/username/password credentials to connect to the SSRS report server. | \n
| \n \n \nSSRS_Credential_UserName \n | \nThe username to use when using domain/username/password credentials to connect to the SSRS report server. | \n
| \n \n \nSSRS_Credential_Password \n | \nThe password to use when using domain/username/password credentials to connect to the SSRS report server. | \n
| \n \n \nSSRS_Credential_UseDefault \n | \nIndicates when connecting to the SSRS report server if it should use default network credentials or not. You must provide domain/username/password if this is false. | \n
You can however override these settings, or specifically supply them if they are not configured in your config file, for any individual report using the SSRS Report View.
", "author": { "name": "Gareth" }, "tags": [ "Triple Lock", "Reporting", "Enterprise Tools" ], "date_published": "2021-01-24T00:50:57+00:00", "date_modified": "2021-01-30T18:44:47+00:00" } ] }![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/Venn.png\")
![\"\"](\"https://web.lemontree.app/support/_framework/_bin/Images/DataTableColumn.png\")