We have a table in the HANA DB with two columns of following data types
DeliveryDate : SECONDDATE// store values like : 2010-01-11 13:30:00
NewDeliveryDate : Date // will store values like: 2010-01-11
How to write sql script to extract the date value from the source column(DeliveryDate) to the target column (NewDeliveryDate) ?
Could you help us with suitable HANA SQL script function to achieve this
Assigning the date part of a seconddate data type to a date data type does not require using a SQLScript function.
It is sufficient to perform a type conversion and this can even be an implicit conversion during a value assignment.
// implicit conversion by assignment
// assigning the seconddate value to a date data type implicitly converts the value, leaving the date part
NewDeliveryDate = DeliveryDate;
// explicit conversion
// this is the preferred option as it makes the conversion explicit.
NewDeliveryDate = to_date(DeliveryDate);
Check the documentation for details on the conversion functions.
Related
We have a source as a flat file which consists of a date column in format 19/08/2013.
We have a target in oracle table which consists of a date column in format 11-AUG-13.
When we are trying to pass the source column value in target using expression TO_DATE AND
TO_CHAR like
**source column is A ---> Source column
v1=TO_CHAR(A)
O1(output column)=TO_DATE(V1,'DD-MON-YY') we are getting the below error.
Invalid date: [19/8/2013]. The row will be skipped.**
Can anyone please help where I'm going wrong.
Thank you
You need to convert the str to date properly and then infa will load them.
Change the mapping like this -
Change data type in source to a string. read data as string.
Then use your expressions but change the to_date function like below.
v1(var column, data type string)=A
O1(output column, data type date)=IIF(IS_DATE(V1,'DD/MM/YYYY'), TO_DATE(V1,DD/MM/YYYY'),null)
IS_DATE - will check if the data is a date or not, if yes then only it will try to convert to a proper date else put null.
3. Then connect O1 column to a date type in oracle target.
This will make sure all data are loaded and none skipped.
The following query is returning one extra row than when the query is run in database:
select distinct employeeId as facilityId,0 as numberOfRequests
from If_User
where role='Facility Staff'
and employeeId not in (select distinct facilityId
from IF_Request
where requestStatus='C'
and allocationTime like '09-12-16%');
This is returned in JDBC:
FacilityID numberOfRequests
8585 0
7427 0
2545 0
Where the actual data in SQLDeveloper is:
FacilityID numberOfRequests
8585 0
7427 0
This is caused by relying on the implicit data type conversion that is triggered by using LIKE on a DATE column. LIKE is only for character values. The LIKE forces Oracle to convert the date value to a string. When run from SQL Developer other rules apply for the evil implicit data type conversion then when you run this through your application.
Use proper date literal instead e.g.
where trunc(allocationtime) = date '2016-12-09'
If that needs to be a parameter from within Java, use a PreparedStatement and pass an instance of java.sql.Timestamp using setTimestamp() do not pass String values for DATE or TIMESTAMP parameters.
Oracle's DATE always contains a time part and and therefor you have to use trunc() on the column value to normalize that to 00:00:00
Never use LIKE on a DATE, TIMESTAMP or NUMBER column!
This question already has answers here:
SQL Server and implicit conversion of types
(2 answers)
Closed 8 years ago.
What is the difference between implicit conversion and explicit conversion in SQL Server?
An explicit conversion occurs when you use the CONVERT or CAST keywords explicitly in your query.
An implicit conversion arises when you have differing datatypes in an expression and SQL Server casts them automatically according to the rules of datatype precedence.
For example nvarchar has higher precedence than varchar
CREATE TABLE Demo
(
X varchar(50) PRIMARY KEY
)
/*Explicit*/
SELECT *
FROM Demo
WHERE CAST(X AS NVARCHAR(50)) = N'Foo'
/*Implicit*/
SELECT *
FROM Demo
WHERE X = N'Foo' /*<-- The N prefix means nvarchar*/
The second execution plan shows a predicate of
CONVERT_IMPLICIT(nvarchar(50),[D].[dbo].[Demo].[X],0)=[#1]
Both the explicit and implicit conversions prevent an index seek in this case.
Implicit conversions are not visible to the user. SQL Server automatically converts the data from one data type to another. For example, when a smallint is compared to an int, the smallint is implicitly converted to int before the comparison proceeds.
GETDATE() implicitly converts to date style 0. SYSDATETIME() implicitly converts to date style 21.
Explicit conversions use the CAST or CONVERT functions.
The CAST and CONVERT functions convert a value (a local variable, a column, or another expression) from one data type to another. For example, the following CAST function converts the numeric value of $157.27 into a character string of '157.27':
CAST ( $157.27 AS VARCHAR(10) )
Implicit means that the database engine will convert the data type automatically, a process invisible to the user.
Explicit means that you must specify how the data type should be converted. If you don’t specify how SQL Server should convert the data types to do what you want (explicitly), it will try to guess your intentions (implicitly).
link
Implicit conversion is a conversion in which you don't have to bother about the conversion. SQL Server automatically converts the data from one data type to another. For example, if a smallint is compared to an int, the smallint is implicitly converted to int before the comparison proceeds. Suppose two column exist such as num1 in smallint and num2 in int.
you want to compare them(whether equal). You have to write:
Select ..... where num1 = num2
nothing required for the conversion.
Explicit conversion is a conversion in which you have to describe the conversion in your hand. Explicit conversions use the CAST or CONVERT functions. For example, a column date1 written in '21.01.2013'. it is in a varchar format according to the provided data/table. you want to compare with another column date2 which is in '21/01/2013' format. It is a date but provided in a varchar format as well. To compare them(whether equal) you have to write:
select ....... where cast(date1 as date) =cast(date2 as date)
I have to run column checks for data consistency and the only thing that is throwing off my code is checking for character lengths for dates between certain parameters.
SEL
sum(case when ( A.date is null or (character_length(A.date) >8)) then 1 else 0 end ) as Date
from
table A
;
The date format of the column is YYYY-MM-DD, and the type is DA. When I run the script in SQL Assistant, I get an error 3580 "Illegal use of CHARACTERS, MCHARACTERS, or OCTET_LENGTH functions."
Preliminary research suggests that SQL Assistant has issues with the character_length function, but I don't know how to adjust the code to make it run.
with chareter length are you trying to get the memory used? Becuase if so that is constant for a date field. If you are trying to get the length of the string representation i think LENGTH(A.date) will suffice. Unfortanatly since teradata will pad zeros on conversions to string, I think this might always return 10.
UPDATE :
Okay so if you want a date in a special 'form' when you output it you need to select it properly. In teradata as with most DBs Date are not store in strings, but rather as ints, counting days from a given 'epoch' date for the database (for example the epoch might be 01/01/0000). Each date type in teradata has a format parameter, which places in the record header instructions on how to format the output on select. By default a date format is set to this DATE FROMAT 'MM/DD/YYYY' I believe. You can change that by casting.
Try SELECT cast(cast(A.date as DATE FORMAT 'MM-DD-YYYY') as CHAR(10)) FROM A. and see what happens. There should be no need to validate the form of the dates past a small sample to see if the format is correct. The second cast forces the database to perform the conversion and use the format header specified. Other wise what you might see is the database will pass the date in a date form to SQL Assitant and sql assitant will perform the conversion on the application level, using the format specified in its own setting rather then the one set in the database.
For example the following query works fine:
SELECT *
FROM quotes
WHERE expires_at <= '2010-10-15 10:00:00';
But this is obviously performing a 'string' comparison - I was wondering if there was a function built in to MySQL that specifically does 'datetime' comparisons.
...this is obviously performing a 'string' comparison
No - if the date/time format matches the supported format, MySQL performs implicit conversion to convert the value to a DATETIME, based on the column it is being compared to. Same thing happens with:
WHERE int_column = '1'
...where the string value of "1" is converted to an INTeger because int_column's data type is INT, not CHAR/VARCHAR/TEXT.
If you want to explicitly convert the string to a DATETIME, the STR_TO_DATE function would be the best choice:
WHERE expires_at <= STR_TO_DATE('2010-10-15 10:00:00', '%Y-%m-%d %H:%i:%s')
But this is obviously performing a 'string' comparison
No. The string will be automatically cast into a DATETIME value.
See 11.2. Type Conversion in Expression Evaluation.
When an operator is used with operands of different types, type conversion occurs to make the operands compatible. Some conversions occur implicitly. For example, MySQL automatically converts numbers to strings as necessary, and vice versa.
I know its pretty old but I just encounter the problem and there is what I saw in the SQL doc :
[For best results when using BETWEEN with date or time values,] use CAST() to explicitly convert the values to the desired data type. Examples: If you compare a DATETIME to two DATE values, convert the DATE values to DATETIME values. If you use a string constant such as '2001-1-1' in a comparison to a DATE, cast the string to a DATE.
I assume it's better to use STR_TO_DATE since they took the time to make a function just for that and also the fact that i found this in the BETWEEN doc...