Snowflake - error converting binary to geography - snowflake-cloud-data-platform

I am running the following query:
select ST_GEOGRAPHYFROMWKB('110f00000104f100000052da1bd4f13254c188db68e89cb042c1bab88d2ed53254c1b8969077baaf42c126c2860f513354c178e09c711faf42c1361ac057563554c1f875e0cca3b042c170ce88e2043654c1c8293a8a46b042c134ef38c5083754c120f46c964ab142c13c4ed1150b3754c16866660ea6b242c13ab4c842753854c1e8f21f9a95b242c16619e2f0763854c1f897dd7397b242c1a679c769833854c1e04f8dd748b342c114ae47b9dd3854c1a0d6347fb5b342c1b0946518463954c1601058d93cb342c1d0b359a56c3954c198d409985fb342c1164850e0703954c140bd529629b442c1bafc87bc483a54c1e0361ae0a3b542c1f831e672f23a54c1482575eabeb442c1faedeb58543b54c1881f632617b542c148bf7dc1a03c54c1f8285caf66b842c146037817903e54c130ff216d8bb742c1c442ad49ba3e54c19006f04678b842c100917e2bae3f54c1e83fa4a75cb842c1e8482ec7574254c168bc740b60b342c1e2e995fa864254c15839b46899b042c118b7d13cb34354c198779c4ad2b042c17c6132a9454454c1a011a51557b142c1941804eeda4654c1d8f0f46243b442c1b6847cc02d4754c13892cbbfc1b442c1726891a13b4754c1e0718acedfb442c17aa52c1f354854c1d0f7539353b642c13480b7c0b14854c1b059f5b911b742c1287e8cf5ba4754c170d71242fdb842c104560e098f4754c128e483e651ba42c16ec5fede9c4854c1a0703de28cba42c160764f422a4954c10893a96a5abf42c194a98261074a54c1d022db0135c042c134ef3815404a54c1900f7a3615c142c152499dc8224554c1f08e532cd4d342c13e575be18b4554c1580e2d5adfda42c14c378915cd4754c1c005124c56e742c11ec9e58fd44654c19087855aa4ed42c156302a01a44854c1c8e53f1c9cf342c18273467c5d4a54c108c58f391bfe42c1b6a67977b34a54c138014d3cae0243c122fdf6b1614a54c12085eb71b80643c1b22e6e1b084954c1f00dbed8db0b43c1f6285c2f6e4854c1285c8f32991543c1c6feb25b6b4a54c14850fc98741f43c188635d246d4c54c178c72972c42443c1a01a2f01694c54c1c898bbd6212843c1827346d8954b54c1306ea359b02b43c1a067b39e474b54c1989999f1362c43c1e6d022d7c24b54c180aeb612c82c43c1b6847cfca24b54c1c0a8a4061c2d43c18c4aeab0d54954c1e81da7703b3143c148bf7d2d8e4954c1285c8fca5c3143c19418045e0f4554c180b7409a0b3a43c162c3d3ebdc4354c1e0718af6be3b43c1acfa5cd9fa4354c10088f4832f3c43c15839b41c2f4254c1a879c7f9973f43c190a0f88db04354c1302aa9bb574943c1e63fa417e24454c160fe43aa084b43c1a0abad18a24354c198bb9698305143c19c559f0f904354c160e5d0ba635143c1ee5a42c24f4354c17081044d725143c11c9e5ea94c4354c140cf6685d95143c14260e5783f4354c1f8e46129f05143c1a60a4615d84254c1d834efe8e05743c1d066d597564054c1f08e5394d15543c1827346e4853c54c1f07c3f65c45143c118b7d1347a3b54c17824972f8e5143c108ce19b12a3a54c19006f0de8a5043c1d200defefc3654c17814ae2fc74b43c1d6e76af7c42f54c118d9ced77a5143c1c68f314b342f54c148378919aa5243c18c4aeae8ce2e54c1f8e46161805543c1b437f8fa8a2f54c130ff2175e25c43c15a423ec45d3254c1904aea64e86743c1f831e6f69a3354c150840dd7436843c17a58a8f9e13154c108121497467043c1d6e76a3bc03154c1c039233a9e7843c1668863f91c3254c1b003e75ca17a43c1d8a37059143354c1508d9756c27a43c1000000c0343354c148ea0424177b43c16ec5fe92583354c180b740f23f7b43c1ac3e579f853254c128f69775fe7b43c1f03845b76f3254c1c0d32b8da27e43c120b0728ca63154c1a813d0a4408043c1643bdf97a43154c100098a8f408043c1ac8bdb40a03154c13055309a4d8043c1de718ac2513154c160984c2def8043c18ab0e171983054c10846258da68143c1726891fded3054c1e8043451c58143c1b0506b5ed83054c188c95461348243c142ad6972663054c1604bc847d88143c1f263cce1762f54c198c420807a8343c112f241b7012f54c130d49ac6ea8243c1c0caa1b9522d54c148ea047cfa8343c15c6dc58e322d54c1d000dee2358543c160764f46ce2b54c1403ee8f94f8843c1a6bdc143542754c110e02d08b98b43c1aeb662efde2654c18841603dd48b43c138d6c5cd352454c12875027ab58843c1ce3b4e59062454c1c8c3425d528843c186eb51b4e92354c1403ee801528743c1d8a37015c22354c190a0f8e1508743c13cdf4f09a62354c148d8f0c4bb8643c1065f9898972354c1c0ec9eac588643c1a4923a091b2354c1e07a14ae498643c1240681710b2354c148c807a5c48643c1900f7a0aab2054c1b8d100ee918543c1365eba71b82054c188855a63298743c1dcd781efd91f54c150158c6a758843c124b9fc27c21f54c140f163e4018943c1365ebaa5231f54c130c4b1ce4b8743c1cc10c7361b1e54c1d878e99e6a8743c1d49ae6658f1d54c1f00dbe40968843c1cae53f54071d54c1888ee49a328b43c1842f4cc2041b54c158c1a834678843c1b8af03c7e11a54c1887cd0bb168843c1e04f8d07311b54c1f897ddfb5b8743c1083d9badfb1a54c180d0b3b16e8743c124b9fcffd71a54c1a8a44e38158743c1c264aa242f1a54c100f77530c08743c12aa913502c1a54c170b5159b9d8743c110e9b7d7741954c170ac8b2bc78743c1fca9f196301654c1a8f1d2ede18d43c118b7d150aa1454c168226cf0908c43c10e2db231061054c1c05296a1c18943c196b20c09e40e54c1a067b37aad8743c176be9fe6700d54c1c0e31415128643c19c33a2b4400c54c1e04f8d1f3e8043c17cd0b3b55f0954c1f80fe96faf7e43c134ef38f5070854c198438b3c997c43c1643bdfd75a0754c110363c3d0e7c43c1f4fdd4e8330754c1a0923ac9ff7a43c17e6abc54820654c1489d8026a87a43c17ac729569b0554c180b7406a3b7c43c1c420b06e6a0554c1b86b09f9737c43c176be9faac60554c1d81b7ce16f7743c10ad7a3a4430554c11873d74a0b7543c1aa13d094eb0554c1304ca6d29b7643c1aa825165ac0654c1f8cbee51bd7643c1de9387051e0754c198559fa3367643c11a51da67060d54c1a8825199246b43c1fed478f9951154c100098af7356543c12653059b0a1154c140cf66ad846143c134ef38a5101154c18051498dab5f43c1bce31409eb0e54c198d40940fc5343c190a0f81dca0a54c100098a2f634e43c14ef38e277e0954c1d88173d65e4543c152499d1c920854c178c7293ae84143c190a0f8f94a0554c1b01c5a5ca63f43c1742497830c0454c1e0020902b43c43c12aa913e4090354c190b96b11ef3c43c138d6c5097a0254c1705f071ec33b43c1065f9830230254c1e83fa4e7493843c1a067b35202fe53c1604bc8770e3a43c110c7bab022fc53c13870cee84a3843c15cb1bfcc1bfb53c1a089b091223843c18204c56351f753c188a7575a813f43c1f853e365e6f653c180b740d2d74343c1708104ed2ef553c1a0abadb8b34343c12497ffa0f4f453c188db6840654343c1a089b05d19f553c1d03b4e71f33f43c18e06f0a6a4f353c1881f6336d83b43c1d85f763f33f253c160dc468b133943c1c876be933cf353c1686ff01d9d3843c194f606977af353c1180de02de63643c132e6aeede2f653c140575bf97d3243c12e6ea34577f753c1f07c3fed982e43c1fccbee7d8df753c1e0718a961b2a43c16619e2906cf653c1383cbdea952143c180d93d155df653c1f041cf561e1543c1bada8ac50bf553c1b02e6e6b930a43c1c0ec9e7c60f353c140575b010e0a43c14c3789618ff153c188d2dee8e90843c194180496ddf053c11895d479000843c1560e2de6e9ef53c1f0f44a59bf0743c1e8d9ac7ab0eb53c130d49a5ed20443c1aa6054c257eb53c1485986a0240443c1bc0512ec46eb53c110143fde090443c1e4141dcd4eec53c1383cbd0a00fe42c17efb3a3ca1ef53c1f8e461d9cef642c11a51daff3ef053c18816d9eec2f442c164cc5d8bb6ef53c188f4dbd72ff242c1a4923a6d76ef53c1381136c4dfee42c158a83595c0ee53c128c2863794eb42c1464772ad45ee53c1a0efa7165ce642c134113618f3ed53c120dbf94e7ae542c16a2bf62b85eb53c18073463477d642c1ece2365ac3ef53c148c8077de2dd42c190a0f8c9f3f453c1f02fbb4f83dd42c1d0b3592984f753c19006f09e63d342c13e79587069f753c150af940514d142c136ab3e8b95f753c1f0d24d1ac4cd42c1d2dee05766f753c11071ac237fcc42c1b459f58d4ff553c1c8eec953e4c942c12e90a0b05ef553c100f775e8e3c842c110583908c4f553c1603255e0f7c742c18e06f0668af753c1782d215fdcc442c1c264aae4c0f753c1b0d85fbe82c242c1fca9f1de99f753c15062107841bb42c1a60a46359cfa53c1a0d634ffc7b542c152da1be406fa53c128c28627e8bd42c13e79588895fa53c100780bfc48c342c1022b873ea1fd53c108ac1c9250c942c1e27a14ca9dff53c1c876beb746d242c1d24d623c9b0154c178e09c3139d742c10c71acbbf30254c128a913e056d942c1dacef757100554c1b89690d7ccdb42c16844699b1b0954c190e4f27f53cf42c15ad3bc9f870954c1a84e406bc2cc42c19ca2232d270a54c100000008a9cc42c1ece23612520c54c170b5152308d042c1cc7f48a3291054c1b8847cc8c1d442c1388941e8aa1054c1d06f5fbf04d542c146037813361554c1181dc95deacc42c188d2dea0861854c1082428de99c442c1e00b93e1b01b54c1805149ad0fc042c1d881736e181c54c1d8f97e92d8c242c1627fd95d2e1c54c150158ce2a2c242c152b81e35431c54c1f041cfa6f2c242c11e3867ec431c54c15096213e4fc342c1ee7c3f8d191e54c19018044e35ca42c1d2915c4ada1d54c198d4097071cc42c1f241cff66f1f54c1a0b437a090ce42c1a089b055e21f54c1888ee4da0cd042c142f163a0282554c1f8a0671b73cb42c1c6feb2437d2954c1f85c6d6dccce42c1de718a363b2a54c1182653b592ce42c1f0164848f12a54c13033339bf0ce42c1705f07626b2c54c1d81b7cb170cd42c14c158c060a3154c128c2866726c142c112363ce9e03254c140cf661d1ec042c1c264aac4d73254c1f8edebe8c8be42c16c567d32753454c16844697f44bc42c146b6f331443554c1887cd043f3b842c150fc185fd63354c1002b870e7bb542c1c0caa15dcc3354c1081b9e5658b342c14a0c023f483254c1806abc6440b142c152da1bd4f13254c188db68e89cb042c101000000020000000001000000ffffffff0000000003');
but I get the error message:
Error parsing WKB input: Type '16777231' unknown.
I cannot find information that can lead me to solve this issue. Has anyone ever faced it?

Your WKB value doesn't look correct. The first byte indicates the byte order for the data:
00 : big endian
01 : little endian
Yours starts with 11.
For more information, have a look here

Related

Encoding (?) issues fetching binary data (image type column) from SQL Server via pyodbc/Python3 [duplicate]

I'm executing this query
SELECT CMDB_ID FROM DB1.[dbo].[CDMID]
when I do this on SSMS 18 I get this:
I'm aware these are HEX values, although I'm not an expert on the topic.
I need to excute this exact query on python so I can process that information through a script, this script need as input the HEX values without any manipulation (as you see in the SSMS output).
So, through pyodbc library with a regular connection:
SQLserver_Connection("Driver={SQL Server Native Client 11.0};"
"Server=INSTANCE;"
"Database=DB1;"
"UID=USER;"
"PWD=PASS;")
I get this:
0 b'#\x12\x90\xb2\xbb\x92\xbbe\xa3\xf9:\xe2\x97#...
1 b'#"\xaf\x13\x18\xc9}\xc6\xb0\xd4\x87\xbf\x9e\...
2 b'#G\xc5rLh5\x1c\xb8h\xe0\xf0\xe4t\x08\xbb'
3 b'#\x9f\xe65\xf8tR\xda\x85S\xdcu\xd3\xf6*\xa2'
4 b'#\xa4\xcb^T\x06\xb2\xd0\x91S\x9e\xc0\xa7\xe543'
... ...
122 b'O\xa6\xe1\xd8\tA\xe9E\xa0\xf7\x96\x7f!"\xa3\...
123 b'O\xa9j,\x02\x89pF\xb9\xb4:G]y\xc4\xb6'
124 b'O\xab\xb6gy\xa2\x17\x1b\xadd\xc3\r\xa6\xee50'
125 b'O\xd7ogpWj\xee\xb0\xd8!y\xec\x08\xc7\xfa'
126 b"O\xf0u\x14\xcd\x8cT\x06\x9bm\xea\xddY\x08'\xef"
I have three questions:
How can this data be intepreted, why am I getting this?
Is there a way to manipulate this data back at the original HEX value? and if not...
What can I do to receive the original HEX value?
I've looking for a solution but haven't found anything yet, as you can see I'm not an expert on this kind of topics so if you are not able to provide a solution I will, also, really appreciate documents with some background knowledge that I need to get so I can provide a solution by myself.
I think your issue is simply due to the fact that SSMS and Python produce different hexadecimal representations of binary data. Your column is apparently a binary or varbinary column, and when you query it in SSMS you see its fairly standard hex representation of the binary values, e.g., 0x01476F726400.
When you retrieve the value using pyodbc you get a <class 'bytes'> object which is represented as b'hex_representation' with one twist: Instead of simply displaying b'\x01\x47\x6F\x72\x64\x00', Python will render any byte that corresponds to a printable ASCII character as that character, so we get b'\x01Gord\x00' instead.
That minor annoyance (IMO) aside, the good news it that you already have the correct bytes in a <class 'bytes'> object, ready to pass along to any Python function that expects to receive binary data.

rsProcessingError - Reporting Services Error - rsErrorReadingNextDataRow

I have ran into a strange issue in one of my SSRS reports. I get the following error:
"An error has occurred during report processing. (rsProcessingAborted)
cannot read the next data row for the dataset Defect_Summary. (rsErrorReadingNextDataRow)"
Whenever I run this dataset's query in query designer, or in management studio, the query runs fine. However, when I run the report in report builder or on the server I get the above error. After researching I have found that the issue has something to do with my parameter.
I have a parameter #PO (Production Order) where the user will provide an 8 digit number i.e. 11002575. In my query I have the following line: OrderNr / 10000 = #PO. In the database, OrderNr is of type bigint and will have a value such as 110025750020. I divide this number by 10000 so that the 8 digit #PO parameter equals the OrderNr such as 11002575.00 = 11002575. I used to use LEFT(OrderNr, 8), but found it slowed down the query so this division has worked better for me.
Anyway, here's the strange part: When I first encountered this error, and after researching, I changed my parameter to type integer (from text). This fixed the problem temporarily and the report ran fine. Then I encountered it again, so I changed the type back to text, and again, it fixed the problem temporarily and the report ran fine. I keep going back and forth with this temporary fix and have not been able to find a permanent resolution to this error, it just keeps coming back after a while of working and then all I know to do is keep going back and forth from integer to text. Can anyone help me resolve this error permanently?

Potential Loss of Data reading from CSV with decimal

I have read a large number of questions and answers on this and I still can't get it to work.
I have a csv like the following:
Field1;Field2;Field3
CCC;DDD;0.03464
EEE;FFF;0.08432
...
When I attach a Flat File Source, in SSIS, it gives me the following:
[Sample CSV [2]] Error: Data conversion failed. The data conversion
for column "Field3" returned status value 2 and status text "The value
could not be converted because of a potential loss of data.".
I have already changed the output to DT_DECIMAL, with 5 as the scale value, in the advance properties but I still get the same error.
Any clue on this?
It seems like a simple solution that I am somehow overlooking.
Thanks!
There are many values that cannot be converted to DT_DECIMAL, you can detect the values that cause this error by utilizing of the Flat File Error Output which redirect the rows that are causing errors when loading data.
Helpful Links
ERROR HANDLING IN SSIS WITH AN EXAMPLE STEP BY STEP
SSIS error when loading data from flat files

PhpStorm 10 strange database query execution warning

I started using PhpStorm 10 and I faced strange database query behaviour (Sybase IQ), namely I'm getting error:
[010P6] 010P6: A row was received and ignored. java.io.IOException: JZ0EM: End of data.
But query executes and I'm getting relevant result.
010P6 - A row was received and ignored.
Description: An unexpected object of type 0xD1 was encountered in the result set being processed and was ignored. Action: Check the query that generated the result set and correct as required.
Can somebody explain what should I correct? The only guess I have is that it comes long char data in the output.

mfl conversion for exponential data

In OSB, We are facing issue in mfl conversion from double exponential data to unsigned zoned decimal. It is failing because of exponential data(0E -7).
Input : 000000 in binary format --> mfl transforms it to 0E-7 --> again we try to convert this 0E-7 to binary ( But here mfl transformation fails). It occurs only when 0 comes as a value but if it is some other value, it works fine. Has anybody seen this before?
Peace & Cheers.
It was bug in OSB, its been rectified in the latest update patch from oracle. :)!

Resources