double and Int32 join in macro but not in normal workflow

[MartWClimber]

I've got an macro somebody created a while ago. (2020) right now i'm diving into this macro because there are some issue related to this macro.

macro: (if I run the macro the red ! will disappear and workflow doesn't error) 

I found that this macro is using a join tool with a strange configuration(see screenshot).

both the input's are created using a macro of there own and what those macro's do are simply changing the path.

when I copy over the macro with the join to a different workflow that is a normal .yxmd type change the input's to normal input tools (same files that are outputs from the macro's)

I get the error (can't join because double and int32 don't match) in this normal yxmd file.

within the macro when I run it I don't get the error and Alteryx seems to think everything is fine. 

even when I run the macro as an macro in a different yxmd workflow it doesn't error.

Is there a reason Alteryx does this, or is this some sort of bug?

[Luke_C]

Are you positive the outputs of the macros have different data types? The only thing I could think of is the data type is being assigned automatically in the macro, and when you manually use the inputs it's read differently. 

Without sample data it's tough to say exactly what's going on. 

[npariso]

It's really difficult to tell what's going on here without seeing the process behind this macro. I would suggest putting a select tool before each of the join anchors and see what field types are coming through the macro.

[MartWClimber]

@npariso  and @Luke_C 

I've added the logging from the macro and I see the following: 

Warning - ToolId 704: Tool #6: Joins on Double or Float are not recommended due to rounding error.

tool 6 is the join.

remember this is an old macro. I thought that that type of joins are not possible within ALteryx.

unfortunately I cannot share the macro (company policy)

[Luke_C]

Hi @MartWClimber 

That's a pretty standard warning that happens if you join on double fields or floats. That seems to confirm what we think but we were asking what the data types of the fields are coming out of the macro. Like @npariso said, put a select tool and see if the fields are different data types. 

[MartWClimber]

@Luke_C ,

I've added the select tool before the join and see that the data-types are indeed different. int32 vs double

within the this macro that join is used to validate the real data flow.

so the real data (1M+ records) flow to  this macro seperatly form that snippet above. that snippet above creates an validation flag that is append to the real data (1+M records). after that the flag is filtered and pushed out of the macro.

the issue I'm facing is that it looks like the flag was never created because the macro on our acceptance  didn't push out the data. on our production the data was pushed out of the macro. 

NOTE: the macro in ACC and PRD is using the same macro yxmc file.

[MartWClimber]

@Luke_C  or @npariso is there a possibility that because let's say or ACC environment is on server1 and the PRD environment is on server2 as well as the macro file (server2)

that because of a network glitch all the data is dropped because when running the ACC workflow it flows in server1, then goes to server2 for the macro part and back to server1 to do some otherthings in the ACC workflow?

[esmalley]

It's a warning, not an error, and it might work okay for the most part. You will end up with the occasional row that fails to join properly though, since floating-point numbers are prone to rounding problems that leave little 0.0000003's and such in them. If you know what degree of accuracy you require, you could try setting the data types within the macro using Select tools - fixed-decimal numbers rather than doubles or floats, or ints if you don't need anything after the decimal at all.