Connectivity Issue

[mcupito]

Is it possible to update (as in change the text in a box) without having it affect all of the same fields with the same ID? I want to be able to change 2 fields in a subform (in the event that they are entered wrong), however the fact that they are linked with the PK is preventing an isolated change to a single entry, instead it changes all because they have the same PK.


Thanks,
Mark

[zmbd]

mcupito:
You will need to provide some information about the table relationships, how the form is designed, for example:

tblone
[tblone_pk] primary key, autonumber
[tblone_field1] text(25)indexed-required
[tblone_(....)] more fields

tbltwo
[tbltwo_pk] primary key, autonumber
[tbltwo_fk_tblon e] numeric-long, 1:M with tblone
[tbltwo_(....)] more fields

We prefer to not have the database attached at this point:
Please understand, many of us cannot or will not d/l un-requested attachments. This has absolutely nothing to do with who you are... In my case, such d/l are prohibited by my ITSec staff. For many others, it is part of "safe computing/best practices" not to d/l such files. A practical example as to why can be found here http://bytes.com/topic/access/answer...l-ms-products. this unfourtunate Member opened a file from a trusted source and is now haveing all sorts of issues!

[mcupito]

I feel as though due to the way these tables are connected, trying to change the LOB_Abbr and the CompanyAbbr in the subform changes their values in their respective tables, which is a big issue. What I need to happen is I want to be able to edit the Company_Abbr or LOB_Abbr on that subform ONLY, not in the tables.

However, looking at the table setup, the way the subform table (ServiceTemp) is connected to the other tables is through Keys. So I can see why editing an entry is changing all of the others, I am just not sure how to isolate it.

I really hope this is enough info, I am at my wits end here folks.

Thanks
[imgnothumb]http://bytes.com/attachments/attachment/7183d1378308498/srvtmptbl.png[/imgnothumb]
[imgnothumb]http://bytes.com/attachments/attachment/7184d1378308498/lobss.jpg[/imgnothumb]
[imgnothumb]http://bytes.com/attachments/attachment/7185d1378308498/cmpss.jpg[/imgnothumb]
[imgnothumb]http://bytes.com/attachments/attachment/7186d1378308634/frm.jpg[/imgnothumb]
[imgnothumb]http://bytes.com/attachments/attachment/7187d1378309576/rltnshp.jpg[/imgnothumb]

[Rabbit]

Isn't this the same question as your other one?

[mcupito]

Rabbit, while it is similar, this one is much more focused and condensed. The other thread was getting sloppy and misguided. Now that I have narrowed down the issue I felt as though it would increase efficiency in assisting the viewers.

[zmbd]

McUpito;

It really sounds as if eithre the database or the form was not setup correctly to begin with - I really suggest looking carefully at the form and how the record set to the form is established, then make sure the controls have the correct bound state to the recordset and then the correct rowsource as this is the most common mistake made... the ROWSOURCE is NOT always the same as the RECORDSOURCE for the form.

You need to understand the basics better before we can really provide any help.

The following site is not my favorite site due to the age now; however, the Basics are still solid. I've also sent you a PM about the following site as the Author is a bit biased against VBA, which in 95 was not as kind to us as it is now. MS Access 95 Tutorial

[mcupito]

I agree, zmbd, something is amiss. Thank you for your resources and guidance. I've begun taking a look at your references.

I am stuck on this issue, as it is the final issue holding this db back from production.

I suppose I will continue to experiment and see if something works.

[zmbd]

cool... we do want to help... we just need to get you the proper tools first :)

Hang-in-there!!!! We'll help you get this thing sorted out, may just take walking on hot coals (ouch, :-O )

[mcupito]

I am going to try to have an update button for each record, have that open a new form that displays the data row from the form, use 2 combo boxes to inhibit mindless entries for Company and LOB, have an 'Update' button - Append query that inserts the new data into the ServiceTbl and a 'Cancel' button that will take the user back to the previous form.

I don't imagine I will need a 'Delete' button, since each row is identified by an autonumber PK, which I was use as a control for the Edit Button, and the new data will be appended to that row ID.

Is this logical?

[mcupito]

Solution: I created an Edit (Command) Button, which then opened the form. I used the ServiceID for each row of data to limit changes and also changed the origin of the information to the ServiceTbl, and used queries to filter data.