To project BLOB into CLOB in Oracle I can do this query:
SELECT ent.ID, to_clob(ent.blob_string) from entity_1 ent;
However, I could not find the to_clob equivalent operation in H2 to see my data in H2-console. How I can do that?
It depends on content of your BLOB. In H2 Console you actually can see BLOB and other binary values as is in hexadecimal representation without any additional functions around them.
You can use CAST(ent.blob_string AS VARCHAR) (or CAST(ent.blob_string AS CLOB)) to convert a binary string to a character string explicitly, but such conversion uses different encodings in different versions of H2. Old versions use hexadecimal representation, new versions use UTF-8. You can use UTF8TOSTRING(ent.blob_string) function for UTF-8 conversion in old and new versions. There is also RAWTOHEX(ent.blob_string) function, but its behavior is also different between different versions of H2 and its compatibility modes.
Related
I know I can do the conversion very easily using C# or any other number of programming languages, however, I want to know if I can do the conversion of a column that has EBCDIC encoded text so that the result of the query is in a readable string such as ascii encoded.
Ultimately, I will import the data into SQL Server and I know SSIS can do it, but before I do that, I want to exhaust any paths that are not SQL language.
For example a little know combination of built in functions available in DB2 SQL or SQL-Server 2008
Here is an example of data
Data as stored in DB2: 0xC6C3C3C1E3C5D9D7C9D3D360F8F840
Text: FCCATERPILL-88
The C# conversion is so easy so I included it here:
System.Text.Encoding ei = Encoding.GetEncoding(37);
textBox1.Text = ei.GetString(allBytes.ToArray())
I'm not an AS400 admin so I'm not sure what to do with what is being suggested in the comments.
i'm trying to grab some data out of a table. The Variable is VARCHAR 30000 and when I use COBOL EXEC SQL to retrieve it, the string is returned but without the necessary (hex) Line Feeds and Carriage Returns. I inspect the string one character at a time looking for the Hex Values of 0A or 0D but they never come up.
The LF and CR seem to be lost as soon as fill the string into my cobol variable.
Ideas?
If the data is stored / converted to ebcdic when retrieved on the mainframe, you should get the EBCDIC New-Line characters x'15' decimal=21 rather than 0A or 0D.
It is only if you are retrieving the data in ASCII / UTF-8 that you would get 0A or 0D.
Most java editors can edit EBCDIC (with the EBCDIC New-Line Character x'15') just as easily as ASCII (with \n), not sure about Eclipse though.
I have seen situations where CR and LF were in data in the database. These are valid characters so it's possible for them to be stored there.
Have you tried to confirm that there really are CR and LF characters in the database using some other tool or method? My Z-Series experience is quite limited, so I'm unable to suggest options. However, there must be some equivalent of SSMS and SQL Server on the Z-Series to query the DB2 database.
Check out this SO link on querying DB2 and cleaning up CR and LF characters.
DB2/iSeries SQL clean up CR/LF, tabs etc
Well, I believe this could be dialect dependent (both COBOL and DB2) but if it were me I would be using FOR BIT DATA on the VARCHAR in the table definition. Your issue could also relate to the code page defined for the database in which the table resides.
I routinely store all kinds of binary, EBCDIC and Unicode data mixed within the same VARCHAR FOR BIT DATA column with no problems, and all you are trying to do is include CR & LF. My approach works in both DB2 z/OS and DB2 LUW.
I hope this helps.
I will like to know what entity is responsible for doing the encoding conversions necessaries to accomplish a SQL command successfully. For example: you have several places where output a SQL command.
SELECT title from T1 where title='tÃtulo'
This may be execute from within the database client (which I assume it reads the database encoding and encode its commands after that) but what happen when this is a string in a programming language whose string encoding is not the same as the database?
Where the conversion takes place? In the class that connects to the database? The database and the connector do some kind of agreement when they are handshaking?
I'll love some information about this topic or some link where I can read about it.
Thanks in advance.
Case Java + MySQL
Internally in Java String is text is Unicode encoded.
In a Java source text should have the same encoding that the java compiler uses. A wrong matching between editor and compiler would mess up string literals.
Java thus transfers a Unicode string to the JDBC driver, the database client library.
The MySQL connections string can indicate which encoding to use in the client library to communicate with the database server. useEncoding=UTF-8, so Unicode, would be a good international choice.
The database can set a default encoding.
As also any table.
As also per column (say one for Hindi one for Chinese).
Besides the encoding, also the collation (sorting order of strings) is language and encoding specific. And have to be considered too.
If I'm using utf-8 encoding for a character set that would use the character set for non-Cyrillic european languages, can I use varchar/char, or should I use nvarchar/nchar?
is there a huge sql processing time penalty for using nvarchar?
internal data representation for nvarchar is UTF-16. AFAIK you cannot change it, so you better use nvarchar for parameters.
MSSQL doesn't support UTF-8 natively, so use nchar.
You must make sure that your code is consistent about the character sets it inserts as that means the RDBMS won't. MSSQL does support UTF-16, so you might consider using that charset for your application instead.
I have a function which maps java to SQL types.
As I want to store binary data, is there any type defined by the SQL standard which I can use both in PostgreSQL and hsqldb?
The SQL 92 standard does not define a binary type. PostgreSQL has a bytea type, hsqldb has a binary type.
For a very portable (if not efficient) solution, convert the binary to base64, and store it in a string.
BINARY and VARBINARY are defined by the the SQL Standard. The Standard is currently at SQL:2011 (after 92, 1999, 2003 and 2008). HSQLDB supports all the core data types defined by the Standard.
The PostgreSQL BYTEA is similar to VARBINARY. You can define the BYTEA type in HSQLDB as a VARBINARY type with a large maximum size:
CREATE TYPE BYTEA AS VARBINARY(1000000)
SQL has supported binary types since 1999: [https://mariadb.com/kb/en/sql-data-types/]. Vendors have had over a decade to add support for binary types, and most SQL databases do.