Grails in memory H2 DB is not supporting to_date function..
so the suggestion I got by going through the forums is using 'EXTRACT' function.
But not sure how to replace the following to_Date with Extract.
to_date(currentDate,YYYY_MM_DD HH:MM.ss)..
Extract -?
You could either:
Use the built-in function parsedatetime(dateAsString, formatString)
Create a user defined function
Related
I was originally using LISTAGG to do the union of strings in oracle.
Searching for PostgreSQL I get: string_agg
I don't know if there is any way to have a function that works in both applications.
I have to do it from the query since I can't create functions
thanks for your help
Thank you all for the help, in the end I did it through functions and sub-query
For a specific reason of a requirement, instead of using a VIEW, I use an Oracle pipelined function to get data in a table.
It works perfectly using Native Query:
"select * from (table (PAC_FOO_PIPELINED.FUNCTION_BAR(:fooDate, :barDate)))"
The problem is that I need to use QueryDSL. If I use native query, it would be necessary to rewrite a lot of code that is now bound to abstract methods that were implemented using QueryDSL.
Can anyone tell me if it is possible to perform this select through QueryDSL?
I want to use extract(DAY from date) function in Oracle FastFormula. However I am getting error when I used above. Is there a similar seeded functionality that I can use for this purpose?
By looking at the function reference for OracleFormula, it seems that you have no other option than calling TO_CHAR with the appropriate format to achieve the desired result. based on the doc's example:
mesg = 'Birthday is: ' + TO_CHAR (birthdate,
'DD')
We are moving our database from Oracle to SQL Server. My queries make extensive use of Oracle's nvl function. In SQL Server, the function to use is isnull(). If possible, I'd like to start getting my queries ready by changing them to use isnull(), while still on Oracle. My idea is to create a wrapper function isnull() in my schema and change my queries to use that function instead. That way when we switch database platforms, my queries are already using the new function.
Is there a way I can create a wrapper function in Oracle called isnull() that accepts and returns any datatype? Or do I just have to have multiple isnull() declarations, overloaded for all the expected data types?
Another approach might be to use COALESCE instead of NVL, since the syntax for COALESCE is the same in both Oracle and SQL Server. Still, the goal (if it is your goal) of having identical SQL that works efficiently (or even works at all) in both Oracle and SQL Server may not be realistic.
The only way in PL/SQL to have multiple overloads for the same function would be to create them in a package. You can create a package that includes a number of different overloaded IsNull functions that accept and return different data types and use those in your queries. Of course, that does mean that you will have to include the package name in your code. It's potentially easy enough to remove the package name when you move to SQL Server but it won't be an exact migration.
I am using two different databases for my project,
Oracle and Apache Derby, and am trying as much as possible to use the ANSI SQL syntax supported by both of the databases.
I have a table with a column amount_paid NUMERIC(26,2).
My old code, which was using Oracle db, needed to retrieve value in this format
SELECT LTRIM(TO_CHAR(amount_paid,'9,999,999,999,999.99'))
How can I convert a numeric value to such a string in the format '9,999,999,999,999.99' using ANSI sql syntax?
I think this is the wrong approach. The format mask is for display purposes, so it really ought to be the concern of the presentation layer. All your data access layer should do is merely execute:
select amount_paid
from your_table
where ....
This syntax will obviously work whatever database your app attaches to.
Then put the formatting code in the front-end, where it belongs.
My knowledge is not encylopedic but as far as I know there isn't an ANSI function to do what you want (although I'd be glad to find out I'm wrong :-). CONVERT converts between character sets but does not, as best I can see, do the formatting work you want. CAST converts values between data types but, again, doesn't do formatting.
If Derby doesn't support the Oracle-style TO_CHAR function you may have to roll your own function, let's call it MY_TO_CHAR. In Oracle the implementation might be
FUNCTION MY_TO_CHAR(nValue IN NUMBER,
strOracle_format IN VARCHAR2,
strDerby_format IN VARCHAR2)
RETURN VARCHAR2
IS BEGIN
RETURN TO_CHAR(nValue, strOracle_format);
END MY_TO_CHAR;
In Derby you'd want to define this function in a similar manner, taking the appropriate value and format and invoking Derby's equivalent of TO_CHAR with the Derby formatting string.
EDIT: I agree with #APC - a lot of these issues disappear if you don't require the backend to do what is basically front-end work.
Share and enjoy.