I've created a simple contact database with three tables, Corporate, Contact, and Country. I've created a LightSwitch application on top of it and am trying to create a countrycode lookup. i.e. on the new Corporate screen, for countrycode field have a lookup list coming from the country table.
How can I do this? If I was writing a SQL query it would purely be:
SELECT CountryCode
FROM Country
In the query designer it makes you create filters, I don't want to add any filters! Also, I've created foreign keys, unique key constraints but LightSwitch doesn't seem to recognise them and complained when I was importing my tables?
* UPDATE *
Error below
Normally, if relationships are set up correctly, this would just happen for you automatically. LightSwitch is very good at this actually.
If I understand correctly, your data source is an external SQL database, that you've added into your LightSwitch application as an attached data source. If there was a relationship between the Client table & the Country table, then LightSwitch would create the look-up combo box in the Client screen automatically. But it's not enough to just have a foreign key column, you have to create a relationship between the two tables.
You don't mention what the columns are in your tables, or more importantly the column data types are. The Country table should have an integer primary key, plus a text column for the name. In the Client table, it should also have an integer primary key, plus an integer foreign key. The relationship should be created in the Client table between its Country foreign key column and the Country table's primary key column.
You mentioned that LightSwitch "complained" when you were importing your tables. What was the error message?
Related
I am new to postgres and building out schemas for an institute. I was sent the most current data given by the institute. I built out a schema and created primary keys and foreign keys based on the UUIDs. When building the schema I would wrangle the big csv file in R studio and pull out each table based on the unique traits. I would then upload the unique tables/csv files to DBeaver. In DBeaver I would then join the table IDs back onto each table based on the unique trait to populate the foreign key. Finally I would then remove redundant columns that were needed to join the foreign key and primary key and add primary and foreign key constraints.
The institute has now sent me new data for the schema. What is the appropriate method to upload new data to each table following wrangling in R studio and how does the database know how to populate foreign keys if the unique columns are not present in the tables any more?
Side not, this data base is not fully normalized on purpose. We wanted to keep the schema simple for ease of backend querying from people who do not know databases.
Building relationship/adding foreign key based on uniqueness.
update survey s
set visit_id =
(select v.visit_id
from visit v
where (v."date", v.survey_time, v.site) = (s."date", s.survey_time, s.site))
I have 2 tables: ZDEPARTMENT and it's text table ZDEPARTMENTT
For table ZDEPARTMENTT.DEPARTMENT the domain is ZDEPARTMENT
and the domain ZDEPARTMENT does not have a associated value table.
Yet, the SAP system makes the correct suggestion for foreign key for ZDEPARTMENTT.DEPARTMENT as ZDEPARTMENT.DEPARTMENT
How is SAP able to make the correct suggestion even if the domain of the foreign key field does not have any value in VALUE TABLE field?
In my application I'm creating a case having a supervisor, but as the supervisor can be either an employee or an external supervisor, I'd like to be able to save either an employee id for the internal reference or a string for the name of the external supervisors name.
How should I implement this? Is having a table "case" and the sub-tables "case_internal_sv" and "case_external_sv" the way to go?
There's not a lot of information in your question on which to base an answer.
If there is common data and functionality across all types of supervisors then you will probably want one table to hold that common data. That table would establish the primary key values for supervisors and the case table would have a foreign key into this table. Information that is unique to either internal or external supervisors would go into separate tables and those tables would also have a foreign key back to the common supervisor level data.
This design is superior because you only have one place to go in order to find a list of all supervisors and because you can enforce the supervisor / case relationship directly in the database without a lot of code or additional constraints to ensure that "one and only one" of two columns is populated.
It's sufficiently superior, from a database point of view, that I'd consider using this design even if the data for internal and external supervisors is completely disjoint (which it's unlikely to be).
If your database allows you to define multiple primary keys you could have field employee and field employee_type combine to form the unique primary key. If not you could have an autogenerated primary key for the table and have a field for employee type and a field for employee_id.
What database are you using?
Having tables too normalized can do more harm than help. You should evaluate the benefits/drawbacks of having sub-tables based on your requirements.
A simple solution can be to have a 'sv_type' column in 'case' table. And have two columns
'internal_sv_id', a nullable foreign key to the employee table
'external_sv_name', a nullable string to save external name.
Then check for supervisor in one of these two columns based on the 'sv_type'
This design might not fully conform to 3rd normal form, but it can save lot of costly joins and allow integrity with employee table.
As for me, I'd go for the simplest solution in case of doubt.
I am attempting to create a relationship between two tables in Access 2013. The PROJ table has many fields, with the primary key being PID, which is a randomly generated auto_increment number. I would like to use this as the foreign key for another table (JDD) to create a link between them. The primary key for JDD is another non-randomly generated id, UII, and I want the the PROJ table to autopopulate the PIDs into the JDD table. However, logically, I would assume that since it is a randomly generated number that there is no way to connect them and have them auto-populate unless I manually attached the PID to each UII. Is there anyway around this? Access would let me create the relationship but I couldn't find the plus signs to auto-populate data in the Datasheet view.
Thanks!
I have a table named Communications which contain a user's contact numbers. This can either be a Home, Mobile or Fax number. I'm storing them all in one table and identifying them using a Type column. (0 = Home, 1 = Mobile, 2 = Fax). Communications table has a foreign key UserId which maps to my Users table to show User to Number relation. I want to have a constraint so that each user can only have at most one of each Type of number. What would be the best way to model this?
I'm using Database Diagram in SQL Server Manager Studio 2008 and would like a GUI-ish answer as opposed to SQL query if possible.
You can add a NumberType table, containing the values 0,1,2 as primary key in column NumberType, and add a foreign key from table Communications.NumberType to NumberType.NumberType. This way table Comunications will only be able to contain values 0,1,2 (or whatever NumberTypes you define).
Then you add a primary key (or unique index, if you want some other primary key) to table Communications on columns NumberType and UserId. This makes sure that each user may only have one number of each kind.
Simply use composite key {UserID, NumberType}
It also a good idea to keep {UserID, PhoneNo} unique and to make sure that a phone number is of one type only; while allowing for more than one user to have the same phone number, say home phone for a family. In that case you can try something like this
Note: implement AK (alternate key) as a unique index.