I have defined the following variable
var result = from report in firoozehDataContext.Reports select report;
now if i want delete One of the columns in the variable, how do i it?
Unless you have grave concerns about performance, this seems like the kind of thing that should be handled at the UI level and not in your data access code.
I get the impression that you are taking the results of this query and binding to a grid or list with auto-generated columns. However, it is much easier (and safer) to control which columns are visible in a grid than it is to dynamically build a SQL SELECT query. Auto-generated columns are really only appropriate for scaffolding scenarios.
Another good reason why I would recommend against doing what you're doing is that every time your end user decides to hide (or re-show) another column, you're forced to re-run your entire query. This is almost certainly not what you really want.
I would simply select all the columns that could be available and hide the ones that shouldn't be available as part of the UI code.
Use the Dynamic Linq Library
Description related to Linq2Sql by Scott Guthrie
You are interested in the part about dynamic return values.
Related
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 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
Is it possible with LINQ to do a cross tab query to add new columns? These columns come from a second and third table and need to be converted to JSON to be displayed in a Telerik table.
One table contains the name of the columns that need to be displayed and the other contains the value for the rows of each column, and this relates to the first table, which has the main related data.
I have investigated dynamically creating the extra columns, but also come unstuck as they need to go through JSON serialization, as well as the difficulties of creating new properties within any class dynamically.
Any ideas would be helpful.
Regards
Mark
I hope this helps, although I'm not sure I understand completely what you're asking ...
Since you're serializing to JSON anyway (and so presumably are not overly concerned with schema/type info), I would suggest just using a Dictionary and populating your data that way. It sounds like you could run some kind of nested loop, cycling through the column names from the one table, and pulling the values from each column from the second table.
EDIT
BTW, it is possible to do dynamic properties using System.ComponentModel, although this seems like overkill from how you described your scenario (you don't require data binding, for instance). Here's a good post on SO, if you're interested: Data binding dynamic data
I have a data access page which gets all it's data from a query of another table, problem is all the textboxs I make on the page and bind the Control source to the matching column then don't allow me to input any text in to use the filter option to search all the results.
I don't want to be able to record any information but if I change page properties to from DataEntry = false too true then it no longer displays the whole section of textboxs.
Anybody know of a way round this or suggestions of other simple solutions to display certain data from the table or all the data from the query in the same/similar way as this?
Edit- Original issue which now requires me to find new solution.
I've used DAP quite a bit -- I even built DAP solutions at Microsoft, and they were wildly popular. I always preferred to use the SQL Server flavor of DAP.. and that allows you to use TWO different types of filters, the standard filter property, in addition to the serverFilter property. The serverFilter property is extremely powerful, and it's incredibly nice to be able to filter things in TWO different ways.
Hope that helps
-Aaron MCITP DBA
The original issue has now been resolved but I had also found these 1, 2 links which guide one through a search feature on DAP's.
What is the best way to re-use reports on different tables / datasets?
I have a number of reports built in BIRT, which get their data from a flat (un-normalized) MySQL table, the data which in turn has been imported from an excel sheet.
In BIRT, I've constructed my query like this, such that I can change the field names and re-use the report:
SELECT * FROM
(SELECT index as "Index", name as "Name", param1 as "First Parameter" FROM mytable) t
However, then when I switch to a new client's data, I need to change the query to the new data source and this doesn't seem sustainable or anywhere near a good practice.
So... what is a good practice?
Is this a reporting issue, or a database-design issue?
Do I create a standard view that the report connects to?
If I have a standard view, do I create a different view with the same structure for each data table, or keep replacing the view with a reference to the correct data table each time I run the report?
What's annoying is the excel sheets keep changing - new columns are added, and different clients name their data differently. Even if I can standardize this, I'd store different client data in different tables... so would I need to create a different report for each client, or pass in the table name to the report?
There are two ways and the path you choose is really dictated by how much flexibility you have architecturally.
First, you are on the right track by renaming your selected columns to a common name since that name is what is used to bind the data to the control on the report. Have you considered a stored procedure to access the data? This removes the query from the report and allows you to set up the stored proc on any database to return the necessary columns. If you cannot off-load to a stored proc, you can always rely on altering the query text at run-time. Because BIRT reports are not compiled (they are XML) you can change the query based on parameters and have it executed for each run of the design. Look at the onCreate event for the Data Set and you can access this.queryText and do any dynamic string substitution you need via JavaScript. Hidden parameters are a good way to help alter/tune the query. If you build the Data Set correctly, the changing of the underlying data could be as easy as changing the Data Source and then re-associating the Data Set to the new Data Source (in the edit data set window). I have done this MANY times and it works well. If you are going down this route, I would add the Data Source(s), Data Set(s) and any controls that they provide data to a report library. With the library you can use the controls in many reports and maintain them in one spot. If you update the library, all the reports using the library get updated as well.
Alternatively, if you want to really commit to a fully re-usable strategy that allows you to build a library of reusable components you could check out the free Reusable Component Library at BIRT Exchange (Reusable Component Library). In my opinion this strategy would give you the re-use you are looking for but at the expense of maintainability. It is abstraction to the point of obfuscation. It requires totally generic names for columns and controls that make debugging very difficult. While it would not be my first choice (the option above would be) others have used it successfully so I thought I would include it here since it directly speaks to your question.