2 of 2 people found this helpful
If you're combining multiple tables worth of fields on a single layout, chances are it's an invalid relationship that is causing issues.
It could be the related record does not exist in the other table.
If you plug this into the data viewer, does it return more than zero?
Count ( V2Table::anyField )
If it returns zero it's either a relationship problem, or the record in V2 doesn't exist.
That makes sense regarding the record not existing in the other table: this database was made long before I got this position and seems to be one of the more primitive ones we have. Trying to figure out a way to relate it within the table. Thanks!
Follow up question: how would I re-relate it? Looks like that the field that relates the two tables got deleted on the second, but it won't let me change the field to rerelate it. Any suggestions?
What do you mean it will not let you change the field?
That sounds like file corruption or file permissions not set correctly.
Please take a screenshot of any errors and upload it here.
those empty fields literally will not let me type in them. those two study key variables should be related, but aren't. every other participant has those two the same. it's hard to show in pictures since it's an act that won't work.
the one thing i figured out is changing the study key to something else lets me change it, but then I need to change every related form, and that is a lot of work. that's going to be the last thing i have to do. if i do a search for 534 in the bottom study key field, the top 534 shows up, but the bottom still stays blank
I thought you meant change the field in the relationship, that would be in the relational graph itself.
You need to investigate the relationship between those two tables to see why a relationship can not be established, otherwise you would never be able to edit the related table from the parent layout.
There has to be something different about the record that doesn’t work, and the record that does.
I am guessing that the record in your related table either doesn’t exist, or is not properly related. Either case would cause an inability to update the related table’s fields (because the relationship is not valid to be able to edit, or the related record does not exist TO edit).
Unfortunately, without access to your system I can’t help further; and I know too little to assist you in troubleshooting those two use cases.
Any idea why if I do a find i the second field for 534, it comes up blank in that one but with the 534 in the first field?
Not without more knowledge of the relationship structure and layout setup and contents.
It sounds like you’re describing a self-join though.
As Mike said, it is difficult to say without knowing more about the database structure. It is possible at the layout level that a separate field is used in Find mode than in Browse mode or it is possible that the relationship is not built on StudyKey so it is finding records in the parent table that have at least one related record with that StudyKey but there are multiple related records (at least one of which has a blank StudyKey in V2). Can you let us know what the relationship is (on the relationship graph) between the V2 table and the parent table?
- The layout is based on study_database?
- You can not enter in fields from V2Checklist?
- study_database::StudyKey contains a value?
- StudyKey in study_database is an auto-enter serial number field or UUID Text Field?
- StudyKey in V2Checklist matches the numeric or text field type of study_database::StudyKey?
- StudyKey in V2Checklist is NOT an auto-enter value?
Assuming all of the above are true, then you should have a valid relationship that allows a record to be created in V2Checklist from a layout based on study_database.
If #3 is false, you would not be able to create a related record.
If #4 is false, you could be overwriting other records via the relationship (non-unique primary key)
If #5 is false, the relationship is invald.
If #6 is false, then the act of creating a record in V2Checklist will never function since the auto-enter key will overwrite the key assigned from study_database.
As I said, every other record that has those same fields with the same relationship works, so it's not an issue with the relationship as a whole.