Join - Omitting data

[TPH]

I have 2 tables that I'm trying to join but unfortunately I don't have control over both tables. I have contral over table A and another department has control over table B. Table A and B contain multiple columns but have a column RATES in common that I'm joining on. The values are unique in table A but table B has multiple lines with various RATES, but only one per line. Table A contains a rate of .3333. Table B sometimes has .3333 for RATES and sometimes has .33 for RATES, which are the same but unfortunately the other department doesn't cooperate after being asked many times. Needless to say I miss the data from table B where the RATES is mistakenly inputted by the other department as .33 since the join excludes that info because .33 isn't in table A.

My question is how do I have the info show up from table B where the RATES is .3333 or .33 without adding .33 to table A? I'd like to know without adding to table A because there are other rates and I don't want to miss any data and produce incorrect information.

Thanks

[orange]

I don't know your situation but if you want the data to "show", you could do this

SELECT *, "Table A"
FROM TablA
where tablA.rate = .3333 or tablA.rate = .33
union
select *, "Table B"
from tablb
where tablb.rate = .3333 or tablb.rate = .33

But if you have different group controlling tables and values that must be compared, your problems are not with JOIN. They are with people and communications.

[TPH]

Problem is that next month the RATES in table B can be entered as .333 and I wouldn't know I missed that data until somebody came back and said the data's incorrect. I was wondering/hoping there was a way to use the LIKE or some other command, but believe that can only be used if the RATES in table B are longer than the RATES in table A (.3333). Plus there are 30 plus rates in table A that are joined to table B, which is a monthly table. I agree the main problem is with people inputting incorrect data in table B and that's what I'm trying to capture before my reports go out incorrecty.

Thanks

[orange]

I think your problems go beyond the .33 vs .333.
You need to review your table structures. There should not be 2 or 3 different values for Rate in the same application.

What exactly is your table for? Why is your Rate different than the other?
Do you have a data or database administration area?

I don't know what you're matching on nor why. But you have to sort out what the business need is for the information. If it's important then someone in authority has to exert some discipline and get the data values (underlying this business need) comparable and usable.

If you are using different tables and different data with different processes at different points in your business - hoping to make them all fit - you are wasting your time and effort in the current scheme.

It may be possible for you to make a table based on table B for your own purposes. And use the same rate as you do on your Table A. Do your calculations/report and indicate what you have done. If there is some discrepancy, it has to be with table B related processes outside of your control. If the discrepancy is sufficient to get management's attention, the you have the info to resolve the discrepancy.

Often in small business ( and large organizations) people are too busy working to get into the details. But if Rate is important and resulting data/reports intended for comparison, they won't compare if the parts and pieces are using different data, processes and rates.