Easy one I thought....

[Guest]

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?

 

[Douglas J. Steele]

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"?.

 

[Chris2]

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?

 

[John Vinson]

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]

 

[Chris2]

Well, that's a programming style issue. Some would agree, some
wouldn't!

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.

 

[tina]

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

 

[Chris2]

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

tina,

Even foreign key columns?


Sincerely,

Chris O.

 

[tina]

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

 

[John Vinson]

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]

 

[tina]

<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

 

[John Vinson]

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]