Whenever I'm considering the option of making a field's contents being extracted from a predefined list, should I make a new table to list exclusively those options, then make a query, then make a form-level lookup field to select it?
This seems like creating A LOT of tables and queries from those tables, just to have a lookup field. I have no idea what the normal number should be, or if there is a clever way of doing queries without creating new tables everytime that I'm not aware of.
For example: I have an Addresses table, and each address can be of three types: home, professional, other. Should I make a table exclusively to list those items and then reference it through a query and a lookup field in a form?
What's the procedure here? Thanks in advance!
Use table lookup when you are going to use this lookup in another entity or you are going to allow the end-user to edit entries of this lookup. In other cases, be free to confine yourself to use constant list of values.
Feel free to ask more.
I'm starting to learn Talend and I'm facing this problem: I have several ID's as an input and I want to make a lookup for each of these ID's to output the obtain data in a Json output.
Here's an image showing what I want to achieve:
http://i.stack.imgur.com/GLVLf.png
I have a tXMLMap with a lookup to the table where I want to find the villains from the villainID's list. The image shows how I can get the ID and Name for one of the villainID's and output it in it's respective json field but this method only works for one ID lookup at a time.
What's the best way to achieve this?
Thanks!
You should be able to copy your second input table 8 times and link all of those back into the tXMLMap component and link those by key as you already have done and join those up to where it needs to go in the XML mapping.
Alternatively you could use a tMap component in a previous step and use that to generate waveNvillainN's dispName by joining the id of your lookup table to all of the waveNvillainN's ids. This should then leave you with all of the necessary fields to populate the XML mapping.
This is the way I could find out to solve this issue, I think it's the same that #garpitmzn and #ydaetskcoR meant but I'm not sure. This works perfectly and was easy to implement but I'd just hope there was a way to have less clutter of components.
http://i.stack.imgur.com/x3AHM.png
http://i.stack.imgur.com/PBeZn.png
just facing a little problem right now.
I have a layout-table that contains one field pages. This should specify for which pages the layout should be applied.
The possible contents are "closed" ranges like '3-5' or open ranges like '3-*'. But it should also be possible to add single pages.
So is there a good way to accomplish a content like that
'3-5;11;15;17-*'
in a single field?
Or do you know better ways?
Is there a possibility to query this field like
SELECT * WHERE IN_RANGE(pages, '5') (Pseudo-Code)
I want to prevent creating a table page because it would contain nothing else and also don't want to do the validation in php.
I am happy to provide more information if necessary.
This is a tricky question i dont see "native" sql option for this.
My first idea was to store information about pages as varchar and implement method to tokenize that string so youll have values which you can then process by sql query.
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
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.