Here is a screenshot of my lookup wizard (sorry, I couldn't change the language from german).
But I don't want to display an ID in "Ort". I want to dispay two values the table has instead.
To generalize this question: "How can I show the values of a foreign key in a lookup instead of the id?"
Cheers
I expect you want to retrieve and save the Ort value as foreign key, otherwise don't bother to include in query. Set up combobox properties like:
RowSource: SELECT Ort, GName, Typ FROM yourtablename;
BoundColumn: 1
ColumnCount: 3
ColumnWidths: 0";1";2"
ControlSource: the field to save Ort in
I NEVER build lookups in table, only comboboxes or listboxes on form.
I know it's a bit late, but hopefully, I can help someone else, who has the same problem. The best solution, in my opinion, is to join two tables in the RowSource property, and select values from there.
Let's assume that you have the Ort and Typ attribute in the same table as GName. Let's call this table: tableofgname. Let's assume you try to read the value of Ort attribute from a table name tableofort.
In this case you should enter something like this in RowSource: SELECT [tableofgname].[GName], [tableofgname].[Typ], [tableofort].[Ort] FROM tableofgname INNER JOIN tableofort ON [tableofgname].[Ort] = [tableofort].[OrtID]
That way you'll see the value of Ort instead of its ID number.
Related
I'm currently working on a survey creation/administration web application with PHP/MySQL. I have gone through several revisions of the database tables, and I once again find that I may need to rethink the storage of a certain type of answer.
Right now, I have a table that looks like this:
survey_answers
id PK
eid
sesid
intvalue Nullable
charvalue Nullable
id = unique value assigned to each row
eid = Survey question that this answer is in reply to
sesid = The survey 'session' (information about the time and date of a survey take) id
intvalue = The value of the answer if it is a numerical value
charvalue = the value of the answer if it is a textual representation
This allowed me to continue using MySQL's mathematical functions to speed up processing.
I have however found a new challenge: storing questions that have multiple responses.
An example would be:
Which of the following do you enjoy eating? (choose all the apply)
Girl Scout Cookies
Bacon
Corn
Whale Fat
Now, when I want to store the result, I'm not sure of the best way to handle it.
Currently, I have a table just for multiple choice options that looks like this:
survey_element_options
id PK
eid
value
id = unique value associated with each row
eid = question/element that this option is associated with
value = textual value of that option
With this setup, I then store my returned multiple selection answers in 'survey_answers' as strings of comma separated id's of the element_options rows that were selected in the survey. (ie something like "4,6,7,9") I'm wondering if that is indeed the best solution, or if it would be more practical to create a new table that would hold each answer chosen, and then reference back to a given answer row which in turn references back to the element and ultimately the survey.
EDIT
for anyone interested, here is the approach I ended up taking (In PhpMyAdmin Relations View):
And a rudimentary query to gather the counts for a multiple select question would look like this:
SELECT e.question AS question, eo.value AS value, COUNT(eo.value) AS count
FROM survey_elements e, survey_element_options eo, survey_answer_options ao
WHERE e.id = 19
AND eo.eid = e.id
AND ao.oid = eo.id
GROUP BY eo.value
This really depends on a lot of things.
Generally, storing lists of comma separated values in a database is bad, especially if you plan to do anything remotely intelligent with that data. Especially if you want to do any kind of advanced reporting on the answers.
The best relational way to store this is to also define the answers in a second table and then link them to the users response to a question in a third table (with multiple entries per user-question, or possibly user-survey-question if the user could take multiple surveys with the same question on it.
This can get slightly complex as a a possible scenario as a simple example:
Example tables:
Users (Username, UserID)
Questions (qID, QuestionsText)
Answers (AnswerText [in this case example could be reusable, but this does cause an extra layer of complexity as well], aID)
Question_Answers ([Available answers for this question, multiple entries per question] qaID, qID, aID),
UserQuestionAnswers (qaID, uID)
Note: Meant as an example, not a recommendation
Convert primary key to not unique index and add answers for the same question under the same id.
For example.
id | eid | sesid | intval | charval
3 45 30 2
3 45 30 4
You can still add another column for regular unique PK if needed.
Keep things simple. No need for relation here.
It's a horses for courses thing really.
You can store as a comma separated string (But then what happens when you have a literal comma in one of your answers).
You can store as a one-to-many table, such as:
survey_element_answers
id PK
survey_answers_id FK
intvalue Nullable
charvalue Nullable
And then loop over that table. If you picked one answer, it would create one row in this table. If you pick two answers, it will create two rows in this table, etc. Then you would remove the intvalue and charvalue from the survey_answers table.
Another choice, since you're already storing the element options in their own table, is to create a many-to-many table, such as:
survey_element_answers
id PK
survey_answers_id FK
survey_element_options_id FK
Again, one row per option selected.
Another option yet again is to store a bitmask value. This will remove the need for a many-to-many table.
survey_element_options
id PK
eid FK
value Text
optionnumber unique for each eid
optionbitmask 2 ^ optionnumber
optionnumber should be unique for each eid, and increment starting with one. There will impose a limit of 63 options if you are using bigint, or 31 options if you are using int.
And then in your survey_answers
id PK
eid
sesid
answerbitmask bigint
Answerbitmask is calculated by adding all of the optionbitmask's together, for each option the user selected. For example, if 7 were stored in Answerbitmask, then that means that the user selected the first three options.
Joins can be done by:
WHERE survey_answers.answerbitmask & survey_element_options.optionbitmask > 0
So yeah, there's a few options to consider.
If you don't use the id as a foreign key in another query, or if you can query results using the sesid, try a many to one relationship.
Otherwise I'd store multiple choice answers as a serialized array, such as JSON or through php's serialize() function.
I have a strange problem. I got some data for cities, regions and countries in CSV format and imported them into MySQL tables.
I have 3 tables and their fields
1. City : id, name, country_code, region_number
2. Region : region_number, country_code, name
3. Country : country_code, name
Now things get a little complicated, as I added an auto-generated id column to the region table, so the region x for country y would be unique.
The thing is: Now i am trying to update city field region_number to hold this unique value (the new id column in region) so I can have relations city->region.
The relation region->country or country->region is OK.
Is it possible to write an update query that would update city region_code (or fill some new column, eg. region_id) with correct values?
If not an query, what could I use to get the correct values into the cities table?
I have arround 3 million records!
If I understant correctly, I think you are looking for something like this:
UPDATE
City inner join Region
on City.country_code = Region.country_code
and City.region_number = Region.region_number
SET
City.new_column = Region.id
However, since there's a relation already between City and Region, I am not sure this is the right thing to do, since it will make the table not normalized.
Now i am trying to update city field region_number to not hold this unique value
The only way you can do this is if the region_number uniquely identifies each region - and if that's already the case then you are wasting your time by creating redundant references. Although frankly, if these really are your table structures, there's no reason for using surrogate keys. And if there's no reason for using surrogate keys then the region and country table are redundant.
Working with MS Access for the first time and coming across a few problems if someone could please point me in the right direction.
So I'm doing a mock database (so it looks silly) just to learn the ins and outs and need some help with DLookUp at the moment.
My database has two tables, with the following fields:
C_ID the PK in Courses and FK in Student
tblCourse: C_ID, Title, Subject
tblStudent: S_ID, C_ID, Name, EnrollDATE
As I said this is just for testing/learning. So what I want is to have a filter that gives me a list of C_ID's based on which EnrollDates are NULL.
so filter is:
Expr1: DLookUp("[tblStudent]![C_ID]","tblStudent","isNull([tblStudent]![EnrollDATE])")
I have also tried with the criteria being
[tblStudent]![EnrollDATE] = Null
Currently I get just blank fields returned. Any help is greatly appreciated, and please ask me to elaborate if my explanation is off.
Thank You!
The correct syntax looks like this:
DLookup("C_ID", "tblStudent", "EnrollDate is null")
You don't need to include the table name when you specify the columns
In Access, you check for Null by using xxx is null or xxx is not null
Note that DLookup only returns one value (if the criteria matches more than one row, the value is taken from any row), so you can't use it to get a list of C_IDs back.
EDIT:
What you actually want to do is select data from one table, and filter that based on data from the other table, correct?
Like, selecting all courses where at least one student has an empty EnrollDATE?
If yes, you don't need the DLookup at all, there are two different ways how to do that:
1) With a sub-select:
select *
from tblCourse
where C_ID in
(
select C_ID
from tblStudents
where EnrollDATE is null
)
2) By joining the tables:
select tblCourse.*
from tblCourse
inner join tblStudent on tblCourse.C_ID = tblStudent.C_ID
where tblStudent.EnrollDATE is null
This is SQL, so you need to switch to SQL View in your query in Access.
What i want to do is this:
a, b - valid.
a, b - valid.
a, c - invalid
f, b - invalid.
So this means the database will allow the same combination of values to exists multiple times but will not allow any other combo to use those values. So it is like a Unique on a combination set. My usecase is i have a group_id and group_name in the table. I dont want peple to mess up the group_name for an ID. So if the first ID of 2 has group_name as 'apple' then all IDs with 2 must be 'apple' and should throw error if 'banana' is entered.
One way is i use a 2nd table and normalize the data but i cant do that here, need to use it denormalized. So is there anyway to enforce this check?
Thanks
maybe validate during insert and update trigger.
I have a table called "users" with 4 fields: ID, UNAME, NAME, SHOW_NAME.
I wish to put this data into one view so that if SHOW_NAME is not set, "UNAME" should be selected as "NAME", otherwise "NAME".
My current query:
SELECT id AS id, uname AS name
FROM users
WHERE show_name != 1
UNION
SELECT id AS id, name AS name
FROM users
WHERE show_name = 1
This generally works, but it does seem to lose the primary key (NaviCat telling me "users_view does not have a primary key...") - which I think is bad.
Is there a better way?
That should be fine. I'm not sure why it's complaining about the loss of a primary key.
I will offer one piece of advice. When you know that there can be no duplicates in your union (such as the two parts being when x = 1 and when x != 1), you should use union all.
The union clause will attempt to remove duplicates which, in this case, is a waste of time.
If you want more targeted assistance, it's probably best if you post the details of the view and the underlying table. Views themselves don't tend to have primary keys or indexes, relying instead on the underlying tables.
So this may well be a problem with your "NaviCat" product (whatever that is) expecting to see a primary key (in other words, it's not built very well for views).
If i am understanding your question correctly, you should be able to just use a CASE statement like below for your logic
SELECT
CASE WHEN SHOW_NAME ==1 THEN NAME ELSE UNAME END
FROM users
This can likely be better written as the following:
SELECT id AS id, IF(show_name == 1, name, uname) AS name
FROM users