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.
Related
SSRS matrix table is a great way to generate dynamic fields as long as values exist.
However, is there a way to "always" show these dynamic fields even if a value doesn't exist for them? The report field locations varies based on data availability and users have to add missing columns in Excel manually.
Dynamic fields go from 3 to up to 30 (at least for now based on run by values). Adding these values manually would make the report hard to maintain.
The way I have handled for this is in the SQL. I build a table of all the values I will always want, I cross join that table to my final output table and update/insert values where they need to exist. That way I guarantee the rows, and eventually columns in the matrix, exists even if they end up being null.
Does that make sense?
Jesse's solution is a good one, but if for whatever reason you can't or prefer not to change the SQL you can do it in SSRS by forcing a blank value in the cell with a expression like this:
=iif(IsNothing(Fields!.xxx.Value)," ",Fields!.xxx.Value)
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
Im using MS Access 2003 and within it I have maybe 100 queries in total; I've been tasked with changing a few names in one of the tables and I don't know exactly how many queries use that particular table.
My question is - is there anyway in Access to automatically change the field names in a table used in multiple queries without having to manually update the queries to reflect the change?
For example say query A does this:
SELECT name
FROM tblA
WHERE ...
If i changed the name in the table is there a way to reflect this across all the queries?
Thanks
This is about the only case where Track Name Autocorrect and Perform Name Autocorrect is a good idea.
Why should I use name AutoCorrect? When you work in a database that
has a design that is frequently changed by users, database objects can
stop working if the design of other database objects changes. One way
this can occur is when the name of an object changes, but that change
is not accompanied by corresponding changes to objects that depend on
the original object.
For example, if you create a query that is based on a table named
Customers, and the name of the table is later changed to Customer, the
query that you created stops working because of this name change.
Nothing else is wrong with the query, and if you correct the table
name in the query design, the query works again.
The name AutoCorrect feature can track name changes for you, and can
automatically correct the names of forms, reports, tables, queries,
fields, or controls, such as text boxes.
-- http://office.microsoft.com/en-ie/access-help/set-name-autocorrect-options-HA010256413.aspx
I have an Access form, that uses a query as the data source. This query uses 3 different tables. I would like the form to allow inputs and the input values to populate one of these 3 tables. Currently the form will not allow the inputs. Please advise
Thanks very much in advance, Nathaniel
You need an updateable query: http://allenbrowne.com/ser-61.html, but if that is not possible, there are other approaches.
If the query joining the three tables is already quite simple, you could consider whether you really need all the tables in one form, for example, a form / subform set-up is a very useful way of presenting and updating data from more than one table. Another possibility is a combobox if one of the tables includes look-up data, such as country code / country.
You could remove the data source, and fetch the data explicitly in the open method. It means a little more VBA code, but it may be less contrived that what you are doing at the moment.
I'm creating a form in CodeIgniter that has a paired value- Companies, and CEOs. The idea is, while there is only one Company field with one CEO field below initially on the form, there is a button for me to create more pairs of Company-CEO fields. I have an idea for how to make that appear on the frontend, but I'm not quite sure which is the best way to store it on the backend.
I think in order to combine each Company and CEO field into one value for storing in the MySQL database, I could simply use CONCAT. However, I'm not sure if I should even bother creating such a value. In any case, how would I handle the fact that there are a variable number of Companies (and thus CEOs) for each record? Would I have to store Company and CEO within another value? How could such an array or tuple be handled in MySQL?
Point 1: Do not combine the values. It will give you headaches in code splitting and combining. Make two columns, one for company, one for CEO.
Point 2: In general, when using a database, any time you have a list it gets its own table.
The various JS libraries out there let you handle this with a grid.