 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Queries / December 2005Easy one I thought....
Two tables, each with a field called Service_to. Can't connect them by this field for various reasons. I am pulling each customer number from the first table - the customer numbers are linked. I need to pull only data from the second table where the service_to date is equal to the service_to date in table 1. I am getting an error when I try this by putting "table1.service_to=table2_service2". What am I doing wrong?  SignatureRegards, Bryan Brassell You say that the field is named Service_to in both tables, yet you've got different field names in what you posted. Rather than "table1.service_to=table2_service2", should it be "table1.service_to=table2.service_to"?. SignatureDoug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!) > Two tables, each with a field called Service_to. Can't connect them by > this [quoted text clipped - 7 lines] > I am getting an error when I try this by putting > "table1.service_to=table2_service2". What am I doing wrong? > Two tables, each with a field called Service_to. Can't connect them by this > field for various reasons. [quoted text clipped - 5 lines] > I am getting an error when I try this by putting > "table1.service_to=table2_service2". What am I doing wrong? . Use a period here. Note: As mentioned earlier, if both columns represent the same data, they should both have the same name. Sincerely, Chris O. >Note: As mentioned earlier, if both columns represent the same data, >they should both have the same name. Well, that's a programming style issue. Some would agree, some wouldn't! John W. Vinson[MVP] > >Note: As mentioned earlier, if both columns represent the same data, > >they should both have the same name. [quoted text clipped - 3 lines] > > John W. Vinson[MVP] John, It's true enough that there are no police who will come and take you away if you name your customer identifier: CustomerID, CustNo, CNo, CustNbr, CNbr, etc. in various tables. However, there are many advantages to using only one name for the same attribute. Sincerely, Chris O. well, i can only think of one advantage: it's easy to match up the paired fields when you're setting relationships in the Relationships window, or in the query design grid. on the other hand, whenever you're dealing with two fields of the same name in the same place (a query, for example), you must specifically reference the table name for each field to clarify it's identity. i'd say it's six of one, half a dozen of the other, and i agree with John that it's a programming style issue that each developer decides for him/herself. personally, i never give any two table fields in my database the exact same name. hth > > >Note: As mentioned earlier, if both columns represent the same > data, [quoted text clipped - 17 lines] > > Chris O. > > > >Note: As mentioned earlier, if both columns represent the same > > data, [quoted text clipped - 31 lines] > > hth tina, Even foreign key columns? Sincerely, Chris O. especially those, since they're the field "pairs" that are most likely to wind up together in the same place, such as in queries. again, my personal naming convention includes never giving any two table fields in my database the exact same name. hth > > "Chris2" <rainofsteel.NOTVALID@GETRIDOF.luminousrain.com> wrote in > message [quoted text clipped - 59 lines] > > Chris O. >especially those, since they're the field "pairs" that are most likely to >wind up together in the same place, such as in queries. again, my personal >naming convention includes never giving any two table fields in my database >the exact same name. Begone, vile heretic of the loathsome Disparate Field Naming school! <g> (Actually... you'ld be a Sheretic, right?) As I said... different styles for different folks. John W. Vinson[MVP] <shrug> well, i've never seen any persuasive arguments that the cons of the "every name unique" method outweigh the pros. i've also never seen ditto re the pros of the "identical primary/foreign key pair names" outweighing the cons. i've certainly never had any problems with the "unique" method in the databases i've built, and i've never been one to follow any convention just for the sake of conformity. so i'll continue to use the style that suits me, and to tell anyone that asks that this particular issue *is*, as you say, a style issue - not a programming quality issue. hth > >especially those, since they're the field "pairs" that are most likely to > >wind up together in the same place, such as in queries. again, my personal [quoted text clipped - 8 lines] > > John W. Vinson[MVP] >i'll continue to use the style that suits me, Absolutely. I was teasing of course. Pick a style that makes sense and works, and be consistant, and you'll be in good shape. John W. Vinson[MVP] |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.