Get Inspire insights from former attendees in our AMA discussion thread on Inspire Buzz. ACEs and other community members are on call all week to answer!

Alteryx Designer Desktop Discussions

Find answers, ask questions, and share expertise about Alteryx Designer Desktop and Intelligence Suite.
SOLVED

InboundNamedPipe::ReadFile: Not enough bytes read. Why?

Ahmed_AlZabidi
5 - Atom

Hello everyone.

 

I tried to download data from table in Oracle Database server. 

Alteryx cannot connect to a table. It gives me this error:

 

Error: Designer x64: The Designer x64 reported: InboundNamedPipe::ReadFile: Not enough bytes read. The pipe has been ended.

 

 

I tested it on four machines with the same error. 

 

 

The same problem appears now in an another complex workflow.

So, I want to know why is this error occure?

 

Solutions I found it but did not give me result:

1- extend Dedicated Sort/Join Memory Usage

2- changed temporary files of Engine to another SSD Disk with bigger space

3- I restarted alteryx instance.

4- I work around it with auto fields tool and block until done tool

 

4 REPLIES 4
DanM
Alteryx Community Team
Alteryx Community Team

@Ahmed_AlZabidi typically this error happens when you run out of memory. If you attempt to bring in a smaller amount of data do you get the same error?  Here is a link to the Alteryx specifications that we recommend for using the software. https://www.alteryx.com/techspecs. Also, the sort/join memory usage setting should be lowered as well as that is the minimum Alteryx will use and if it needs more, will look to find available memory.  If this errors started to happen in a previous workflow, then memory usage is more than likely the usage as Alteryx will only use what is available in the environment and will not change the environment.

 

 

RifferX
8 - Asteroid

I wanted to share the results of this error that I happened to go through trying to resolve the last couple of months. Hopefully, this may help someone in the future if they have a similar issue. This was using with Hadoop, BTW.

 

After jumping through a myriad of hoops and troubleshooting with different teams, the Alteryx Client Admin here at my company was able to determine that my ID was pointing to another user “xxxxx.xxxxxxx” and the jobs were getting terminated. This id translation error occurs in some of the servers only, but it was sufficient to eventually cause the jobs to be killed.

MikeD
8 - Asteroid

I had the same issue.  I had a workflow with 1M records x  1400 fields that was running fine and outputting to several formats at the end, including .yxdb and .tbe.  I made a few minor changes and it stopped working.  I cleared all the temp directories, change memory settings per the guidance on the help site, opened up more disk space on all my drives, etc.  Nothing worked.  Finally, I chopped off my workflow four tools before the output write and wrote to an intermediate yxbd.  I first ran it with 25% of the records and it worked fine.  I then ran it with 100% of the records and it worked fine again.  I still need to run those last few tools and the write out to final yxbd and tbe, but chopping the workflow solved my immediate issues.  In general, I have found that breaking my workflows into parts helps with the design, debugging, and execution of them.  I usually have one part of the workflow that joins all data, one to do the heavy analysis, and one to do the output.

rbahrenburg
5 - Atom

I had the same problem Intermittently... Very frustrating. I added memory and it got WORSE... I am using Alteryx to perform ETL to a data warehouse.

I was reading from an Oracle 11.2 database using the native Oracle client. While reading a very large table 3.6 GB, it would stall, then disconnect with a broken pipe. I switched to ODBC for Oracle which seems to have resolved it. Just watch out of oracle limits. When I switched to ODBC, it set fixed decimal fields (in the selector) from 38.0 to 40.0, which of course blew up the out (being written to another Oracle table). Just put back to 38.0 and I was good to go. So far no more broken pipes.

Labels