cancel
Showing results for 
Search instead for 
Did you mean: 

Incorta datatype for a binary data type column?

RADSr
Captain
Captain

Had the goofiest thing happen.

We have series of MVs consolidating result sets.   The origin is SQL against a SQLAnywhere DB.    One of the columns is datatype "binary." 

All was well up until .... yesterday.

Yesterday the last build in the sequence failed because it couldn't find that column.   Investigation found that the first extract has it  ( *now* has it? ) as a datatype NULL.

Downstream the "select *" query didn't recognize the now-datatype-NULL column and failed.

So - did something happen w/ Incorta outside a point release ( we haven't upgraded between working and non-working ) -- maybe a SPARK update?   

And more immediately - can I bring a binary field into Incorta?   Setting it as an INT returned all NULL values  ( complicated by the fact that I haven't confirmed the DB actually *has* values in this column ).  

 

 

-- IncortaOne@PMsquare.com --
2 REPLIES 2

RADSr
Captain
Captain

I punted.  The column is unused in our source DB so I just deleted it.

 

-- IncortaOne@PMsquare.com --

RADSr
Captain
Captain

This got goofier.

After I deleted the column from the source SQL statements ( 37 of them! ) by exporting, editing XML, and re-importing the initial tables worked fine - all showing the proper 200 columns.   My final query doing a union between two sets failed with a message saying one side had 201 columns.   Running it w/ only one side of the UNION showed 201 columns including the column which had been deleted ( even though it did not show in the UI ).

I wound up "editing" ( spacebar => validate ) and doing a full load of the source table to - I assume - update the underlying parquet file to let the downstream loads "know" there were only 200 columns.

Which is a really long way of saying I still don't know what the NULL datatype is for, but I have more time to find out now  😉    

 

-- IncortaOne@PMsquare.com --