I created database with
DB2_COMPATIBILITY_VECTOR = ORA
it should include NUMBER_COMPAT and VARCHAR2_COMPAT set to ON
http://goo.gl/tHSDM8
But when I try to create table with number column like NUMBER(38) it says that number is too long.
It is also case with definition of variable in pl/sql package - varchar2(32767).
Thank you in advance
There are certain differences in how these data types are supported between Oracle database and DB2 -- they are clearly explained in the documentation.
NUMBER(x) maps to the DECIMAL(x) data type, for which the maximum precision is 31. If you need more, use DECFLOAT(34).
The maximum size of VARCHAR data type (for which VARCHAR2 is just a synonym) is 32672 bytes.
Related
I read different posts about this problem but it didn't help me with my problem.
I am on a local db (Microsoft SQL Server) and query data on remote db (ORACLE).
In this data, there is a CLOB type.
CLOB type column shows me only 7 correct data the others show me <null>
I tried to CAST(DEQ_COMMENTAIRE_REFUS_IMPORT AS VARCHAR(4000))
I tried to SUBSTRING(DEQ_COMMENTAIRE_REFUS_IMPORT, 4000, 1)
Can you help me, please ?
Thank you
No MSSQL but in my case we were pulling data into MariaDB using the ODBC Connect engine from Oracle.
For CLOBs, we did the following (in outline):
Create PLSQL function get_clob_chunk ( clobin CLOB, chunkno NUMBER) RETURN VARCHAR2.
This will return the the specified nth chunk of 1000 chars for the CLOB.
We found 1,000 worked best with multibyte data. If the data is all plain text single byte that chunks of 4,000 are safe.
Apologies for the absence of actual code, as I'm a bit rushed for time.
Create a Oracle VIEW which calls the get_clob_chunk function to split the CLOB into 1,000 char chunk columns chunk1, chunk2, ... chunkn, CAST as VARCHAR2(1000).
We found that Oracle did not like having more than 16 such columns, so we had to split the views into sets of 16 such columns.
What this means is that you must check what the maximum size of data in the CLOB is so you know how many chunks/views you need. To do this dynamically adds complexity, needless to say.
Create a view in MariaDB querying the view.
Create table/view in MariaDB that joins the chunks up into a single Text column.
Note, in our case, we found that copying Text type columns between MariaDB databases using the ODBC Connect engine was also problematic, and required a similar splitting method.
Frankly, I'd rather use Java/C# for this.
What is the correct syntax when creating a table in Access with SQL? I have tried DECIMAL, DOUBLE, NUMBER, INT... nothing lets me create an integer category with limiters.
Example:
CREATE TABLE NONGAME (
ITEM_NUM CHAR(4) NOT NULL PRIMARY KEY,
DESCRIPTION CHAR(30),
ON_HAND NUMBER(4), <------- DOES NOT WORK!
CATEGORY CHAR(3),
PRICE DECIMAL(6,2), <------- DOES NOT WORK!
ANYTHING DOUBLE(4,2) <------- DOES NOT WORK!
);
MICROSOFT ACCESS DATA TYPES
The following table shows the Microsoft Access data types, data types used to create tables, and ODBC SQL data types. Some types have limitations, outlined following the table.
Microsoft Access data type Data type (CREATE TABLE) ODBC SQL data type
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
BIGBINARY[1] LONGBINARY SQL_LONGVARBINARY
BINARY BINARY SQL_BINARY
BIT BIT SQL_BIT
COUNTER COUNTER SQL_INTEGER
CURRENCY CURRENCY SQL_NUMERIC
DATE/TIME DATETIME SQL_TIMESTAMP
GUID GUID SQL_GUID
LONG BINARY LONGBINARY SQL_LONGVARBINARY
LONG TEXT LONGTEXT SQL_LONGVARCHAR[2]
MEMO LONGTEXT SQL_LONGVARCHAR[2]
NUMBER (FieldSize= SINGLE) SINGLE SQL_REAL
NUMBER (FieldSize= DOUBLE) DOUBLE SQL_DOUBLE
NUMBER (FieldSize= BYTE) UNSIGNED BYTE SQL_TINYINT
NUMBER (FieldSize= INTEGER) SHORT SQL_SMALLINT
NUMBER (FieldSize= LONG INTEGER) LONG SQL_INTEGER
NUMERIC NUMERIC SQL_NUMERIC
OLE LONGBINARY SQL_LONGVARBINARY
TEXT VARCHAR SQL_VARCHAR[1]
ARBINARY VARBINARY SQL_VARBINARY
[1] Access 4.0 applications only. Max 4000 B. Behaviour similar to LONGBINARY.
[2] ANSI applications only.
[3] Unicode and Access 4.0 applications only.
Note: SQLGetTypeInfo returns ODBC data types. It will not return all Microsoft Access data types if more than one Microsoft Access type is mapped to the same ODBC SQL data type. All conversions in Appendix D of the ODBC Programmer's Reference are supported for the SQL data types listed in the previous table.
Limitations on Microsoft Access data types
BINARY**, **VARBINARY**, and **VARCHAR: Creating a BINARY, VARBINARY, or VARCHAR column of zero or unspecified length actually returns a 510-byte column.
BYTE: Even though a Microsoft Access NUMBER field with a FieldSize equal to BYTE is unsigned, a negative number can be inserted into the field when using the Microsoft Access driver.
CHAR**, **LONGVARCHAR**, and **VARCHAR: A character string literal can contain any ANSI character (1-255 decimal). Use two consecutive single quotation marks ('') to represent one single quotation mark ('). Procedures should be used to pass character data when using any special character in a character data type column.
DATE: Date values must be either delimited according to the ODBC canonical date format or delimited by the datetime delimiter (#). Otherwise, Microsoft Access will treat the value as an arithmetic expression and will not raise a warning or error.
For example, the date "March 5, 1996" must be represented as {d '1996-03-05'} or #03/05/1996#; otherwise, if only 03/05/1993 is submitted, Microsoft Access will evaluate this as 3 ÷ 5 ÷ 1996. This value rounds up to the integer 0, and since the zero day maps to 1899-12-31, this is the date used.
A pipe character (|) cannot be used in a date value, even if enclosed in back quotes.
GUID: Data type limited to Microsoft Access 4.0.
NUMERIC: Data type limited to Microsoft Access 4.0.
(More information at the Source)
Limitations on ODBC Desktop Driver data types
The Microsoft ODBC Desktop Database Drivers impose the following limitations on data types:
All data types Type conversion failures might result in the affected column being set to NULL.
BINARY Creating a zero-length BINARY column actually returns a 255-byte BINARY column.
DATE The DATE data type cannot be converted to another data type (or itself) by the CONVERT function.
DECIMAL (Exact Numeric)** Not supported.
Floating-Point Data Types The number of decimal places in a floating-point number may be limited by the number format set in the International section of the Windows Control Panel.
NUMERIC Supports maximum precision and a scale of 28.
TIMESTAMP The TIMESTAMP data type cannot be converted to itself by the CONVERT function.
TINYINT: TINYINT values are always unsigned.
Zero-Length Strings: When a dBASE, Microsoft Excel, Paradox, or Textdriver is used, inserting a zero-length string into a column actually inserts a NULL instead.
(Source)
More Information:
MSDN : Create and Delete Tables and Indexes Using Access SQL
MSDN : CREATE TABLE Statement (Microsoft Access SQL)
Microsoft Docs : Microsoft Access Data Types
Microsoft Docs : Data Type Limitations
Microsoft Docs : Converting between ODBC and SQL Server data types
Microsoft Docs : Limitations of SQL ODBC Desktop Drivers
Wikipedia : Open Database Connectivity (ODBC)
Small addendum by Erik:
You can actually use the Decimal data type in CREATE TABLE queries. However, this requires your statement to be executed either using ADO, or on a database that's been set to use ANSI-92 compatible syntax.
To set your database to ANSI-92 compatible syntax:
Go to File -> Options. Open the tab Object Designers. Go to Query Designer, and under SQL Server Compatible Syntax (ANSI 92), check This Database. Now you can just execute the query. Note that this affects all queries in the database, and affects queries in various ways.
To execute a query using ADO:
In the VBA Immediate Window, execute the following line:
CurrentProject.Connection.Execute "CREATE TABLE NONGAME (ITEM_NUM CHAR(4) NOT NULL PRIMARY KEY, PRICE DECIMAL(6,2));"
Of course, you can execute more complex queries using ADO.
DECIMAL and DOUBLE cannot be used in Access. For a "price", CURRENCY is the best bet. For my other integer, I just used NUMBER and gave it no limiters.
I want to store Japanese(or any language) character in one column of my oracle database table.
I have used varchar2 as data type. when I am trying to insert this character(ꏕ) to this column its stored as '[]'.
Don't know what to do. Need help.
Note:
I tried to change the data type to nvarchar2 still didn't work.
https://translate.google.co.in/?hl=en&tab=wT#auto/en/Kinj%20A%20%CC%88%EA%8F%95%20%C9%82%20%C8%82%20%C4%82%20%E6%82%A9%0A%ED%82%A9%20%C3%84%20%EA%8F%95%20%C9%82%C8%82%C4%82%20%E6%82%A9
Where can practically use this type?
What is the MLSLABEL Oracle datatype?
This theme is very old so it can have practical use of this type?
MLSLABEL : The Oracle PL/SQL datatype MLSLABEL is used to store an
operating system label in binary format. It is used for Oracle Label
Security (which was earlier known as Trusted Oracle MLS RDBMS). The
maximum precision for MLSLABEL column is 255 bytes; its Datatype Code
is "105".
http://psoug.org/definition/MLSLABEL.htm
We have a teradata database that is filled with BIGINT datatypes. SAS is the primary analytic engine for the organization. The SAS access library chokes on BIGINT and therefore forces all code to cast variables into a integer or decimal before returning them to SAS. Example:
proc sql;
connect to database (blah blah);
create table sas_dataset as
select * from connection to database(
select
cast(bigint_var as integer),
varchar_var,
char_var,
from some_table
);
disconnect from database;
quit;
Does anyone know a way to fix this? Possibly a macro for casting variables or SAS access fix? Keep in mind that there are literally thousands of variables in this database that are bigint and making changes to the database is out of the question.
If you can't fix it on the SAS side, you can always create a set of views on the Teradata side to do the casting. Then have SAS access the views:
create view sas_cast_db.some_table as
select col1, col2, cast(bigint_var as decimal(18)), col3
from real_db.some_table;
Since you have lots of tables, it may be possible to write some SQL to auto-generate these from the data dictionary.
The issue is that SAS can only handle a maximum of 15 digits for a BIGINT data type.
SAS have provided a few work-arounds for SAS 9.2 (one mentioned above) for this issue. You can also get your SAS Platform Admin to arrange for the SAS server to be updated so that it truncates the BIGINT fields to 15 digits (obvious caveats apply), or update your LIBNAME statement to set all BIGINTs to be cast automatically.
http://support.sas.com/kb/39/831.html
Sample code
data temp1;
set mylib.bigclass (dbsastype= (id='char(20)'));
run;