I'm have a table storing primary keys written to via a combo box. In need to query the text associated with the stored Primary keys, can pull only the primary key itself. How can I query the text.
I'm have a table storing primary keys written to via a combo box. In need to query the text associated with the stored Primary keys, can pull only the primary key itself. How can I query the text.
My basic question is "why"?
Please give us more context and an example of what you are trying to do.
I have a form "frmProfiles" capturing names, DOB, Conatct info, etc. Its subform captures
three skills via three combo boxes and writes them to a separate table which is huge. The
data source for combo boxes are three tables each with a Primary key and a txt field. Due
to the size of the skills table, i'm writing only the Primary key #'s to that table. I
need to query this skills table (the whole purpose of the application), but need the
text returned from the combo boxes. All I can get is the primary key(s). How Can I get the "Skills"
text (as it appears in the combo boxes) to be returned in a query?
Initially I was capturing the text in the skills table, and it works fine, but due to the number of records, Im changing text to the associated primary key.
Maybe you'll have to post samples of your data and architecture, because I don't see why you write the PK if you can just write the text. It seems you have no way of relating the id, but I'm not sure because of how you describe the combo data sources. To have 3 tables for each suggests each combo row source is a query. Don't know if your concern about the size of the table is valid either, since 2 GB is a LOT of records (unless they're stored images, which I gather they are not in your case). Perhaps you are experiencing a speed issue, which can be caused by things other than the size of a table.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.
No Images. Each combo is limited by the combo before it, and this Company decided to start moving stuff around (move these to that category, split those among these categories, etc., etc. ad nauseum) and it would be easier to move numbers than all that text. Right now about 2300 records. Sounds like I'll need to stay with text and deal with it .
'K. Sounds like the normalization (or lack of it) doesn't readily support changes. I'm thinking now that your reference was to the amount of work it would take to "fix" it rather than a problem with the table size. I'd agree that 2300 manual record updates would not be fun, but it certainly is not a large table, per se.
You might want to consider dumping the data to Excel and auto-filtering the rows. Pretty sure that if you drag a new value down a filtered list, it only applies the change to the visible rows. You might edit a 1000 row subset of records in about 3 seconds. Then migrate the data back to Access. Ranman256 has posted in this forum about an Excel macro to prepend an apostrophe to text values if they don't go back into Access without trouble. As always, only test on copies of data.
We met repeatedly, and I'd ask, "Is this final - is this how you want ?" They assured,"yes." Now they are wanting further breakdowns, shifts and sub-categories. Really not a normalization issue as much as mid-level management disputes.
If you are employed there, I'd say it's not so bad. If they can never make up their mind, I'd call it job security.
If you're contracted for this database, I feel for you.