Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 494
  • Last Modified:

Access Database - Wrong column being saved

Hi,
    I have two tables on my database called;

Data and Providers

Providers is made up of approx. 10 columns which are;

ID, Number, Name etc.

I have a form which has a drop down made up from the providers table, and when a record is saved, it saves the value to the Data table.... however....

On the dropdown box, it uses a SQL script to list the name, rather than the first column of ID, but when the record is saved, it saves it as the ID number, and NOT the name which is in the box on the form.

What am I doing wrong, and what do I need to do to resolve?

Thanks

Damian
0
damianb123
Asked:
damianb123
  • 3
  • 2
1 Solution
 
ButlerTechnologyCommented:
It sounds like the ID is part of the drop-down list and that it is hidden -- in this case the width of the column is 0.  On the data tab of the drop-down, try setting the Bound Column to 2 to see if that corrects the issue.
Tom
0
 
mbizupCommented:
<<
What am I doing wrong, and what do I need to do to resolve?
>>

In the interest of keeping things normalized it actually sounds like you are doing things *right*.

In other words, you should maintain the provider name in ONE table (your providers table), and store the ID in others (such as your Data table).  You shouldn't store the name in multiple tables.  That way if the name changes (typos, etc), you only need to correct it in one place - the ID stored in any other tables is enough to look up the text name/description whenever needed.

(ie: you should leave this as is and adapt/develop your forms and reports to use the ID to lookup the name whenever needed)
0
 
PatHartmanCommented:
As mbizup already said, saving the ID is the correct solution to keep your tables normalized.  To see the text rather than the ID in reports, create a query that joins the two tables and select the text value from the lookup table.  You could use a combo as you do on forms but combos look awkward on reports.

For your own purposes, I know it's nice to see the descriptive value when you open the table but it doesn't take much effort to create a query that shows both.  Just be careful when you make such a query because you can update both sides of the join and you may inadvertently modify the text value thinking it applies only to the record you are looking at but in reality, it would change the value in the lookup table and so actually affect everyone.  So, in a query that joins an order to the customer table so you can see the customer name as well as his ID, if you change order.customerID to a different customer, Access will automatically populate customer.customerName with the correct customer name and the order will be reassigned to a different customer.  However, if you change customer.customerName, the change affects the customer table and that customer's name will be permanently changed where ever it is used.
0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
mbizupCommented:
Pat,

<<  but combos look awkward on reports. >>

Which view are you referring to?  

I've found that combos are a great way to handle relationships like this on reports... they look like combos in design view (and possibly in Report View in more recent versions of Access), but they display just like textboxes in Print Preview and in the print outs -- with the text rather than the ID displayed, and without the 'drop-down arrow'.
0
 
PatHartmanCommented:
I'm glad you got an answer to your question but unfortunately it enabled you to do the wrong thing.  Saving the ID is the correct solution.  You bring up the text value whenever you need it by using a query that joins to the lookup table.  Your accepted solution prevents the use of Referential integrity because you are saving the wrong field as the foreign key which is what mbizup and I were trying to tell you.  You need to save the ID field as the foreign key.
0
 
mbizupCommented:
Agreed.  If you actually implemented that solution, you might want to revisit this question and independently read some articles / tutorials on database normalization.

As an aside, Experts-Exchange generally works best if there is more of an 'exchange' of comments... Your own participation/feedback is always a plus.
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now