Field: "Field Name" is 0 Length

[Mark_Lurie]

I am querying a view on an Oracle database that has fields in it that are null.  I didn't have any issues with this in the prior version of Alteryx but now that I have upgraded to the latest version it's crapping out on me and it's frustrating that it used to work before and now it does not.

When I try test query, I get an error that says: Field: "CLOSEDSTATUS" is 0 length.  As mentioned before, there are many fields that are null in this view.

Short no selecting the null fields from the original view and putting them in downstream using a formula object is there anything I can do on the initial query with the Input Object.

Thanks

[Inactive User]

If these are an integer or numeric fields, you could try casting them as varchar in the select statement and see if that gets by the issue.

[Mark_Lurie]

I ended up doing the following:  cast(null as varchar2(1))

Thanks

[brucedataguy]

I'm using version 2018.1.4.  When working with an In-DB connector and selecting a table (or view), I get this same error when it was fine using version 11.7. 

From what I read, the "solution" is to cast the data type?  I'm not able to add a SELECT tool because the In-DB connector doesn't return the metadata about the table. 

The use of the tools is to make it easy -- now I have to write custom SQL in the In-DB tool to handle varchar2(0) fields? 

I think I need to downgrade to version 11.7.

[randykluver]

I agree, it appears to be a bug in the new version. 

We have a lot of inputs just pulling views that have been built for the business.  Not allowing these fields to come in is detrimental to the 'Self-Service' space, and doesn't seem to align with Alteryx's general line of thinking. 

[jwpetrov]

I'm having a similar issue. Often, I need a "placeholder" column to comply with a table data structure. In V11.7, having an "empty string" for text values worked just fine. Now I'm getting the Field: "xxxx" is 0 length error. I don't really like loading blank spaces in these instances.

By the way, both of these columns are showing in the Select tool as String 1.

I'm having the same issue with 2018.1 and 2018.2.

[randykluver]

To get around this (in the short term).  In our Query, we are using a CAST() function to cast the zero length field as a different data-type  (such as Varchar(4) ). 

I feel this is a work-around, and I hope Alteryx can make a patch to accommodate the zero length field (to even bring it in with 1 character.  

Hope that helps get you unstuck; if this is a barrier at the moment.

Good luck! 

[jwpetrov]

---

@randykluver wrote:

To get around this (in the short term).  In our Query, we are using a CAST() function to cast the zero length field as a different data-type  (such as Varchar(4) ). 

I feel this is a work-around, and I hope Alteryx can make a patch to accommodate the zero length field (to even bring it in with 1 character.  

Hope that helps get you unstuck; if this is a barrier at the moment.

Good luck! 

---

Thanks, Randy...

The query is in Oracle, so instead of '' COLUMN_NAME, I entered this in my code: CAST('' AS VARCHAR2(1)) COLUMN_NAME and now Alteryx is happy again.

I'm hoping someone will send a post when this has (hopefully) been resolved.

[brucedataguy]

Disappointed to hear this bug continues in 2018.2.

Coding queries inside the In-DB Connect tool is ok ... but then I can't copy/paste the connection when another workflow wants different set of data from that same table/view without editing the CAST statements.

How are bugs reported to Alteryx Designer development team?  I was expecting they monitor these posts.  Is there a formal process?  I want to get someone's attention so this gets put into 2018.2.1.

[WayneWooldridge]

I know having to CAST your data fields is less than optimal and as a customer, the experience is tedious.  As a reminder, Customer Support is available to help with and address these types of issues.  You can contact them at support@alteryx.com.  Alteryx has been made aware of this particular issue and it is being addressed.  I don't have an ETA on the release of the fix, all I can say at this point is the issue has been identified and being remedied.