Dave - Not sure which operation you are referring to, a DataManager Merge/Join operation, which combines two tabular data sets into one, or a Collapse values operation for combining two fields into one?

When you say two numbers, you mean two fields both typed Numeric...or is one field typed Text?

Can you post a simple example that shows the issue?

This is a DataManager Merge/Join box. When merging two integers, same happens if I change both to Text. It joins on the value fine. But then at the preview bottom of the box, a null is shown. I have tried re-creating the Merge/Join operation, result is still the same. I can't post any files, I will see if I can recreate in an example. Have you been any to recreate the issue? Dave

Ok, I will try to do that though I am not sure I can recreate it?

Not sure what you dont understand though?? I get two sets of data, that link on a primary key, and then link them with a merge/join box in datamanager, but while they link just fine, the data that comes outy of the box, has a null vaule.

Are the numeric fields the primary key for the merge? Is the resulting single field showing null in the direct preview of the merge block, or further down the flow? If you put a field organiser directly below the merge block, does it report that the primary key is still an integer?

We cannot reproduce the circumstances, and merging on integer numbers as primary keys should produce a single matched integer number field...

Hi Dave - Here is our attempt at reproducing your issue without any of your data. If you open the IOK file you can see we are merging successfully on integer fields and the data comes out as expected. There are no null values.

The only reason I can think of that you are getting nulls is if you are choosing to retain non-matching records from either side.

In any case I think you will have to provide us with an example of this problem in order for us to proceed.

Hi am sure I must be doing somthing silly?!

But here is the issue.

Dave - Thanks for this, but we can't duplicate this data flow without the source file(s)...you can e-mail the source file separately. However, we notice that the IMO Numbers you are using as primary keys/merge fields are not really numbers in the sense that you don't ever do any arithmetic with them. They are really just text identifiers...

What happens if you re-type the IMO numbers as Text values on both sides of the 'upstream' flow before the merge?

Hi,

I've noticed that one field your joining on (IMO.NO) is Text, whilst the other (X03_Imo_number) is an integer. So, in fact your not merging on two numbers, as originally stated. Try using the a field organiser to ensure the field types are the same and you have consistent treatment of separators on both sides prior to joining.

Hi guys,

As started above:-
"This is a Datamanager Merge/Join box. When merging two ints, same happens if I cnage both to text. It joins on the vaule fine. But then at the other end of the box, a null is shown. I have tried Recreating the merge box, still the same."

I have tried with two text and with two ints. With the same results. This is just my original file.

Dave

By the way. Is there a reason why a text and int can't join?

You should be able to join a text and an integer field, however we suspect this may have something to do with your issue, which is why we asked you to change them to the same type.

As Tom suggested can you send us the source files so we can reproduce your problem (you can use the "Replace with snapshot" option on the block to replace the original source (database etc) with a file that you can send us).

Please email them to support@visokio.com.

Dave - OK...now that we have snapshots of all the source files, and to wrap this up for the benefit of others ...despite your having a De-duplicate block above one side of your merge, a single null value (with no duplicates) was passing through from the source file you did not expect to have any nulls. Because there were also many null values on the other (right) side of the merge, you have nulls on BOTH sides. When the surviving merge result field takes on the name of the left side field (where you did not expect any nulls) and then fills with an unexpectedly large number of nulls (which can display first at the top of the field preview)... this makes it look like there was a problem with the merge. In fact, so long as both merge fields are consistently typed (Text, no separators) or (Integer with or without separators) everything was working fine. If you had scrolled long enough downwards in the preview, past all the null values resulting from having nulls on both sides of the merge, you should have seen that after the nulls, all your IMO numbers were in fact there.

We are considering adding a warning to the De-duplicate block to flag whenever a single (de-duped) null value is being passed through...this would have given us all a big hint.

This is indeed part of the problem. I belive that the other part of teh problem was that I was trying to link a comma seprated thousend number with a normall text. Once this was fixed, (by changing both to text) it should have been the end. However when I still saw null IMO's I was very confussed; and this is where the above comes in. I should have checked that.

Thanks again for all your help.