I have HEX data like this (F9F9F9F9) returned from a query. When I checked from IBM link :
https://www.ibm.com/support/knowledgecenter/en/SS2MB5_14.1.0/com.ibm.xlf141.bg.doc/language_ref/asciit.html
F9 = 9 and F9 = 9
Here I should get result as 9999
I jhave around 1000 hex records like this in a table.
How can I convert this hex values to it corrsponding EBCDIC ?
I tried like :
select cast(col char(2) as codebase(37)) from table
How ever, its not working.
THis link is also not working: I'm not sure if its a cobol code or DB2 script. : http://www.ibmmainframeforum.com/db2/topic8785.html
Please help.Thanks.
select cast(col char(2) as codebase(37)) from table
Correct Syntax.
select cast(col as char(2) ccsid 37) as col from table
Generally you don't want to do this over and over so maybe just alter the table.
ALTER TABLE mylib/Z1 ALTER COLUMN JOJOB SET DATA TYPE CHARACTER (
10) CCSID 37 NOT NULL WITH DEFAULT
Or create a view over the table for read only data and read from the view.
create view tablev as
select cast(col as char(2) ccsid 37) as col from table
Related
I am working on a data upgrade issue.
A new column has been added to our Existing DB2 table.
In order to upgrade Client's DB2 table, I am unloading the data from the existing DB2 table with a constant value for the new column(lets say D of type SMALLINT) as shown below:
UNLOAD TABLESPACE XYZ.ABC
DELIMITED COLDEL X'2C' CHARDEL X'22'
PUNCHDDN SYSPUN01
UNLDDN SYSREC01 CCSID(367)
FROM TABLE DB2BG111.table_name
(
A POSITION(*) CHAR(2)
, B POSITION(*) SMALLINT
, C POSITION(*) CHAR(4)
, D (new column) CONSTANT X'0000'
)
While unloading the data, we are using following unload parameters:
X'2C': Column Delimiter
X'22': Character Delimiter
CCSID(367): EBCDIC to ASCII conversion
Problem tham I am facing is, DB2 is adding character delimiter X'22' after the value of the column D in the unload record.
Please note column B is an existing column and is declared as SMALLINT, DB2 not adding character del for this in the unload record.
This may be happening because new column D added here is not declared as a SMALLINT and hence it is not treated like an SMALLINT and DB2 is ending a char del for this in the unload record.
I am just looking for a way to get out of this situation, i do not want my new column D to be character delimited in the unload record.
Any suggestions to overcome this would be highly appreciated.
One option would be to use DSNTIAUL to perform the unload, and select the constant in the select list.
SELECT A, B, C, CAST (0 AS SMALLINT) AS D
FROM TABLE DB2BG111.table_name;
Best regards,
Patrick Bossman
I have a database with one column of the type nvarchar. If I write
INSERT INTO table VALUES ("玄真")
It shows ¿¿ in the table. What should I do?
I'm using SQL Developer.
Use single quotes, rather than double quotes, to create a text literal and for a NVARCHAR2/NCHAR text literal you need to prefix it with N
SQL Fiddle
Oracle 11g R2 Schema Setup:
CREATE TABLE table_name ( value NVARCHAR2(20) );
INSERT INTO table_name VALUES (N'玄真');
Query 1:
SELECT * FROM table_name
Results:
| VALUE |
|-------|
| 玄真 |
First, using NVARCHAR might not even be necessary.
The 'N' character data types are for storing data that doesn't 'fit' in the database's defined character set. There's an auxiliary character set defined as the NCHAR Character set. It's kind of a band aid - once you create a database it can be difficult to change its character set. Moral of this story - take great care in defining the Character Set when creating your database and do not just accept the defaults.
Here's a scenario (LiveSQL) where we're storing a Chinese string in both NVARCHAR and VARCHAR2.
CREATE TABLE SO_CHINESE ( value1 NVARCHAR2(20), value2 varchar2(20 char));
INSERT INTO SO_CHINESE VALUES (N'玄真', '我很高興谷歌翻譯。' )
select * from SO_CHINESE;
Note that both the character sets are in the Unicode family. Note also I told my VARCHAR2 string to hold 20 characters. That's because some characters may require up to 4 bytes to be stored. Using a definition of (20) would give you only room to store 5 of those characters.
Let's look at the same scenario using SQL Developer and my local database.
And to confirm the character sets:
SQL> clear screen
SQL> set echo on
SQL> set sqlformat ansiconsole
SQL> select *
2 from database_properties
3 where PROPERTY_NAME in
4 ('NLS_CHARACTERSET',
5 'NLS_NCHAR_CHARACTERSET');
PROPERTY_NAME PROPERTY_VALUE DESCRIPTION
NLS_NCHAR_CHARACTERSET AL16UTF16 NCHAR Character set
NLS_CHARACTERSET AL32UTF8 Character set
First of all, you should to establish the Chinese character encoding on your Database, for example
UTF-8, Chinese_Hong_Kong_Stroke_90_BIN, Chinese_PRC_90_BIN, Chinese_Simplified_Pinyin_100_BIN ...
I show you an example with SQL Server 2008 (Management Studio) that incorporates all of this Collations, however, you can find the same characters encodings in other Databases (MySQL, SQLite, MongoDB, MariaDB...).
Create Database with Chinese_PRC_90_BIN, but you can choose other Coallition:
Select a Page (Left Header) Options > Collation > Choose the Collation
Create a Table with the same Collation:
Execute the Insert Statement
INSERT INTO ChineseTable VALUES ('玄真');
I'm a newbie working on a postgres 9.5 (dynamic) crosstab query, that has been working fine in general, but I've come up with a peculiar issue with large nearly identical category names and I hope there's an easy solution/explanation.
Requires tablefunc:
CREATE EXTENSION IF NOT EXISTS tablefunc;
Schema:
CREATE TABLE temp_table (id integer, name text, data text);
INSERT INTO temp_table VALUES (1, 'ThisSentenceIsExactlySixtyTwoCharactersLongPlusNumbersAtTheEnd', 'data1');
INSERT INTO temp_table VALUES (2, 'ThisSentenceIsExactlySixtyTwoCharactersLongPlusNumbersAtTheEnd1', 'data2');
Query:
SELECT * FROM CROSSTAB($$SELECT id, name, data FROM temp_table ORDER BY 1,2$$ , $$SELECT DISTINCT name FROM temp_table$$) AS ct (row integer, col_1 text,col_2 text);
Instead of the result I expect, I get:
ERROR: duplicate category name SQL state: 42710
Can anyone please tell me what's going on here, and if there's a simple fix?
Thanks!
I'm guessing it has something to do with the fact that PostgreSQL truncates identifiers (including column names and category names) to 63 characters. Seems like there's an off-by-one error somewhere in crosstab as well maybe. Do your names need to be so long? That's probably the easiest fix. You could also try increasing NAMEDATALEN and recompiling postgres.
https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
I have been trying to export a table from db2 from one external source to another, so far, I noticed that there is an error while I tried to import it on the source table.
I was using this on a shell script:
myDate=$(date +"%Y%m%d%I%M")
myPath=/tmp/test
myDataSource="external"
myTableName=tableSchema.sourceTable
db2 +w -vm "export to $myPath/$myDataSource.$myTableName.$myDate.ixf of ixf
messages $myPath/$myDataSource.$myTableName.$myDate.ixf.xmsg
SELECT * from $myTableName"
After further investigation, it seemed like there was a weird character "▒" being inserted. I checked the source and there wasn't any weird character. SO the after checking on detail I issued this command:
select *
from SYSIBM.SYSCOLUMNS
where
tbcreator = 'SOURCESCHEMA'
and tbname = 'SOURCETABLE'
for fetch only with ur;
Which showed that the CCSID on the source columns is 37. I did the same on the target schema and the CCSID for the columns is 1208.
When I tried to export the table again forcing it to convert to CCSID 1208 adding modified by codepage=1208:
db2 +w -vm "export to $myPath/$myDataSource.$myTableName.$myDate.ixf of ixf
modified by codepage=1208
messages $myPath/$myDataSource.$myTableName.$myDate.ixf.xmsg
SELECT * from $myTableName"
This causes the script to work, but I get this warning:
SQL3132W The character data in column "COLUMN" will be truncated to size "4".
Said column is the same size on the source and the target but it seems that due to the CCSID I will need to change the size on the target (I can't change anything on the source and changing the CCSID on the target will break things on the target) So, my questions are:
How do I calculate the size needed for each varchar/char column depending on the encoding, for example if a varchar(4) on CCSID 37 will need a varchar(5) to hold a value with CCSID 1208?
Will it be possible to do something like:
SELECT
CAST(COLUMN as VARCHAR(12) CCSID 1208) --and for all columns
from tableSchema.sourceTable;
So I don't lose any part of those strings.
What about the numbers?
Thanks!
At the end, I ended up using this
SELECT
CAST(COLUMN AS VARCHAR(12) CCSID 1208) as COLUMN,
CAST(COLUMN2 AS VARCHAR(12) CCSID 1208) as COLUMN2,
(...),
CAST(COLUMNM AS VARCHAR(12) CCSID 1208) as COLUMNM,
FROM tableSchema.sourceTable;
It converted across codepages and no truncation was raised.
I'm trying to figure out how to insert a .JPG file into a SQL Server 2000 database field of type image using Transact SQL. Thanks.
Use OPENROWSET:
INSERT MyTable (ImageColumnName)
SELECT BulkColumn FROM OPENROWSET (BULK 'c:\myjpeg.jpg', SINGLE_BLOB) AS X
EDITED Whoops, you're using 2000--the previous solution is not supported. You have to use WRITETEXT:
CREATE TABLE MyTable
(
ID INT PRIMARY KEY IDENTITY (1,1),
ImageColumnName IMAGE NULL
)
GO
-- must insert a dummy value into the image column for TEXTPTR
-- to work in next bit
DECLARE #RowId INT
INSERT MyTable (ImageColumnName) VALUES (0xFFFFFFFF)
SELECT #RowId = SCOPE_IDENTITY()
-- get a pointer value to the row+column you want to
-- write the image to
DECLARE #Pointer_Value varbinary(16)
SELECT #Pointer_Value = TEXTPTR(ImageColumnName)
FROM MyTable
WHERE Id = #RowId
-- write the image to the row+column pointer
WRITETEXT MyTable.ImageColumnName #Pointer_Value 'c:\myjpeg.jpg'
There is a tool called textcopy.exe
You can find it under MSSQL\Binn or get it with SQL Server 2000 SP4
Alexander Chigrik wrote a nice stored procedure for usinig it with SQL query:
http://www.mssqlcity.com/Articles/KnowHow/Textcopy.htm
The stored procedure found in this tutorial worked for me:
Brief tutorial on text, ntext, and image