Barebones table

[Lou_Reed]

The attached table is an integral part of the db. But examine it. I believe that there is something not right about the table.



It gives information that is sketchy at best. We know thta a a person with PersonnelID 3 attended ysnMeetingID 2 and that he/she is from the organization 4.

Now what does that tell us? There is no name of the person, no name of his/her organization and no name or date of the meeting.

Now these missing values are in the db, just not in that table. So what gives?

I know that since it is a table, the only person who will ever see it is me, but is simply gives a lot of information, but so much is missing.

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[Bulzie]

Lou, was wondering where you went, seem days weeks since you posted anything. Thought you jumped the ship.

Of course the correct answer Bob is "This is a relational database so those ID values relate (link) to other tables that have the names and other info you need."

[Lou_Reed]

Okay, but again it seems so bare bones. Just looking at it tells a few things and then tells me nothing.

Of course, I am the only one who will ever see it, but what about debugging?

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[orange]

You are showing a query, not a table.
Please show the table definition/design, and the query SQL.

My first guess is that you are using lookup fields in your table, but not enough info to be certain.

[Lou_Reed]

My mistake in showing a query and not a table and then talking about it as a table. My error. Still the same rule applies, the query output is quite barebones. I have not looked at this project since August and I expect to present it soon. Thus a routine examination (after being away from it for a few months) just brought up these questions.

I really appreciate the help, but again table or query a human looking at it could be left in the dark on many things.

Respectfully,

Lou Reed

[Bulzie]

Not really Lou, it all starts with the tables, their structures and Relationships. Queries are based on tables or other queries so you can always reverse engineer those to see which tables or queries they use, fields, criteria, etc. Make sure to check for any table relationships as that might affect how data is entered or deleted also.

[Minty]

It's no different to a list of phone numbers, or zip codes.
You can look up the human friendly names / addresses but they won't get your call connected or mail delivered as the machines don't work with that bit.

It's all in the numbers

[Micron]

Still the same rule applies, the query output is quite barebones

It's simple. Include the fields in the query that contain the descriptors. If you can't, you need to include other tables that contain these descriptors and join them between their PK and FK fields. If you can't do that, then the tables structure is wrong.

[Lou_Reed]

Thanks for all of your help. it is very appreciated.

Respectfully and Gratefully,

Lou Reed