I have some sql statements, which i am using for Oracle. This sql statements are used by a programm from me.
I want to support Oracle and SQL-Server with my program without having different sql statements for Oracle and SQL-Server.
Which alternative can i use for the specific Oracle SQL-Statements:
to_char(FIELDNAME, 'YYYY')
to_char(FIELDNAME, 'YYYYMMDD')
to_char(FIELDNAME, 'DD.MM.YYYY')
The sql statements have to work for Oracle and SQL-Server.
Even if at a first glance the SQL implementation from two different vendors looks similar, when working with real life enterprise applications you will stumble upon a large number of differences, and I am only talking about SQL, when comparing PL/SQL with T-SQL there is hardly any resemblance left.
When trying to reduce the usage of two databases to only common functionality, you will loose a lot of their power, you could as well use a txt file on the file system.
One elegant solution, as someone already suggested, would be to leave the columns in the database as DATE data type and extract your data in the application code that stands above the database, if any. For example, in Java, you will map your database DATE columns to java.sql.Date no matter if that date comes from Oracle or from SQL Server.
Still, if you want to get your formatted data from the database, you could create separate columns that hold the formatted date, for example :
FIELDNAME | FIELDNAME_YYYY | FIELDNAME_YYYYMMDD | FIELDNAME_DDMMYYYY
I don't think there are common functions to do what you want. Oracle supports the ANSI standard extract() function for extracting date parts. SQL Server has separate functions for YEAR(), MONTH(), and DAY(). Oracle uses TO_CHAR(); SQL Server uses CONVERT().
One option is to define the functions YEAR(), MONTH(), and DAY() in Oracle and then use string concatenation (via the CONCAT()) function to combine the data. Or, write specific functions in each database for what you want to do. Or, perhaps, someone has implemented TO_CHAR() in SQL Server and you can grab the code from the web.
Finally i found a solution. Maybe its useful some other people too.
You can set the input format for a date...
Oracle: ALTER SESSION SET NLS_DATE_FORMAT = 'DD.MM.YYYY'
SQL-Server: SET DATEFORMAT dmy
Related
Inspired by the slected answer to Declare a variable in RedShift I am trying to use a query result as the format value in a to_char function call:
WITH tmp_variables as (
select 'YYYY-MM-DD' as date_format
)
SELECT to_char(OrderDate, (SELECT date_format FROM tmp_variables)) FROM Orders
But I am getting an error
TO_CHAR parameter: Second input must be a string literal
How can the tmp_variables's date_format value be used as a to_char format without getting an error or is there an alternative to using to_char where this would work?
SELECT is a SQL operator that work upon data. SQL is compiled before it can operate on data. The basic answer is that this won't work as written.
What you are trying to achieve isn't clear in the question - change date output format for some reason for some set of queries but not others? In the general case you will need to modify the SQL that goes to the compiler which will mean reading some configuration and merging this into the SQL text. If the use case is more limited there may be another way to achieve the desired result but only within some set of limitations.
Some possibilities - You could set a SQL variable with the format literal. Your client can read info and modify the query itself if it is capabile. A stored procedure could be used. A SQL modifier (pg_bouncer?) could live between the client and the cluster and substitute the string based on some other factors. Each of these has limitations and costs.
If you can describe the use case it could generate different / better ways.
I am trying to convert Julian Date to Gregorian/Normal Date(mm/dd/yyyy) in SilverLake DB.
I am using Oracle SQL statements to query SilverLake db. I tried it with:
TO_CHAR(<myfieldname>,'YYYYDDD')
But SilverLake DB is throwing me an error:
Argument 1 is not valid for TO_CHAR function
Would appreciate your help. Thanks in advance.
I am not allowed to post a reply to the previous comment since I am a new user, but this answer also responds there. What you refer to as SilverLake DB is actually a specific vendor implementation (Jack Henry & Associates) of the Db2 for i database, for their SilverLake core banking system. This is the database that comes with the IBM iSeries, a midrange computer also known with it's older name AS/400 (think of a mainframe, just smaller). While antiquated this is still used for legacy reasons, especially in banking systems such as SilverLake.
ORACLE specific commands will NOT work there, other than by coincidence of IBM also using them, and any research you are doing should be referring to Db2 for i, I doubt you will find much content for SilverLake specifically unless you reach to the vendor directly.
I have had luck with the following statement with what you are trying to do:
COGSUP.JDTODATE(<myfieldname>)
this will convert the data type to an ISO Date format, in my humble opinion this should be the only date format used on databases.
If you still need to convert this to the American notation for presentation purposes, you can wrap this with a to_char statement:
to_char(COGSUP.JDTODATE(<myfieldname>), 'MM/DD/YYYY')
Just use to_date() to turn the julian date to a date:
to_date(col, 'j')
Then if you need to represent the date in a given format, you can use to_char():
to_char(to_date(col, 'j'), 'mm/dd/yyyy')
I'm working in a project where I have been explicitly required to not use T-SQL syntax. The application we are using supports T-SQL but we are not allowed to use it to avoid potential migration issues.
My question is: is the SELECT ... INTO statement T-SQL or SQL? If it is T-SQL, is there a specific SQL query to copy an existing table into a new one? (I have tried with CREATE TABLE AS .. FROM but it doesn't work).
Sounds like a very basic question but I haven't been able to find the answer anywhere. Thus, in addition to the question above, it would be very helpful to know if there is a guide/dictionary/website that collects only the standard SQL syntax.
Thanks!
I think they recommend you to use ANSI SQL, instead of T-SQL (SQL Server) or PL-SQL (ORACLE). Considering it as common requirement, every database vendor provide their own way of implementing this requirement. When you use ANSI SQL, you will not have migration issues, when you move from one database vendor to another database vendor.
SQL SERVER
SELECT * INTO new_table
FROM existing_table
ORACLE & ANSI-SQL
CREATE TABLE new_table
AS SELECT * FROM existing_table
is SELECT INTO TSQL or SQL?
Neither. The MySQL documentation claims that SELECT INTO is a Sybase extension to standard sql. As such I don't think you can accurately say it's either of these, but you can say that it's neither. It is indeed used in T-SQL, as well as some other database vendor products, to create a table from a query. The SQL standard says that queries with that goal should be formed as CREATE TABLE blah AS SELECT .... Oracle/MySQL, for example, use the standard form though you can see them use SELECT INTO in a different context, to assign data to variables in stored procedures
If you want to avoid use of this non standard syntax when creating and populating a table then you'll have to:
CREATE TABLE blah (column spec to match query output)
INSERT blah (select query here)
But then you run into nuances like "sqlserver calls it datetime/datetime2 but oracle calls it date/timestamp"
And ultimately you'll probably get into a situation where you just can't use one form of sql to do all you want..
I'd imagine most libraries that do data access on multiple underlying databases have mechanisms to use vendor specific terminology where required
From the answers, it appears you might need to specify which SELECT INTO you're talking about. The other answers seem to suggest there exists some kind of SELECT ... INTO <table-name> when there is also a kind of SELECT ... INTO <local-variable-name list>. The latter is used in embedded SQL for making SQL interact with variables of the host language program. I'm not certain but that variant may also be used in the part of the SQL language that deals with procedures written in SQL (the SQL/PSM part of the standard).
A "reference" that covers "only the standard SQL syntax" is, in principle, the ISO standard document itself, only available by purchase from ISO (and yes, it's ISO not ANSI - ANSI does nothing more than rubberstamping the ISO document after removing all the names of non-US contributors). And not the easiest kind of literature. There are "draft" versions floating around on the internet that might deviate from the published final standards. E.g. http://www.wiscorp.com/sql200n.zip. Note that this is a SQL:2008 draft. Current standard version is SQL:2011. And it's several thousands of pages, so I guess that covers your question "Is all the syntax covered in w3schools standard SQL". (Hint : no)
I know UDF in legacy sql, but UDF need you pass whole row into function, and return whole record, and UDF can't put into select section, this is not real function I need, Is Bigquery Legacy SQL can write function like Standard SQL? (can put into select or where section)
thanks :)
This functionality is only supported in Standard SQL (and as Elliott mentions in the comments, is unlikely to be added to Legacy SQL because it is being phased out).
Across various SQL dialects, what string representation for a Date and/or DateTime would be most likely to be interpreted correctly? Is there an SQL Standard? Are the two answers identical or similar?
EDIT:
For suggestions, can we all please comment with any known SQL dialects that don't comply?
I would bet the ISO 8601 date time standard would most likely be the one.
'YYYY-MM-DDThh:mm:ssTZD'
Or maybe a slight variation:
'YYYY-MM-DD hh:mm:ss'
http://www.w3.org/TR/NOTE-datetime
If you want to be portable across databases, maybe you should consider abstracting everything away using something like ADO or OTL. Pretty much all databases support ODBC connections, and you could just use something like OTL's datetime container to write and read dates.
There's also DATE'2014-07-02', which is accepted by Oracle, DB2, MySQL, and Teradata, but not MS SQL or PostgreSQL.