Convert Julian Date to Normal System Date in Silverlake(USing SQL statement) - sql

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')

Related

Oracle Apex - selecting date with different hours

We have a web application which we store a date from the user. The date is stored on an Oracle 19c database as a date field.
The problem we have is that when we select the date it's coming with different hours, like it's taking into account the timezone or something. So, for example one person can see the date 2021-05-20T13:00:00Z while another somewhere else can see 2021-05-20T12:00:00Z.
Is there a way to prevent this behavior, and have everybody get the same date and time?
Update
Most likely the problem resides in Oracle Apex, not Oracle database!
We use a very old version of Apex, 1.x it seems so maybe this problem doesn't happen on newer versions.
That is often problem when you use, for example, java.util.Timezone,java.sql.Date or java.util.Date type in java instead of oracle.sql.Date

Why date formats are different in APEX and Oracle SQL Developer?

The date format in Oracle SQL Developer looks like DD-MON-YY.
For example 17-OCT-03.
The date format in APEX looks like MM/DD/YYYY.
For example 12/17/1980.
Why are they different?
This might cause the same SQL query not to work on both applications.
I know that I can avoid such problem by using TO_DATE and TO_CHAR functions but I want to understand the logic behind this problem.
Does every application use its own default date format?
Yes, every application has it's own date format.
And even every application can have more than one session, each with a different session format specified for DATEs and TIMESTAMPs.
SQL Developer has it's application level settings defined in the Preferences, Database, NLS page. This is how DATEs will appear unless you issue an ALTER SESSION SET... in your SQL Worksheet.
Or, if you always want a specific format regardless of this setting, build it into your query.
select to_char(sysdate, 'DAY') today from dual;
It's been my experience as well... YES, every Oracle application/tool can have its own default date format, but most just use the default display format set at the database level:
SQL> select name, value from v$parameter where name = 'nls_date_format';
NAME VALUE
--------------------- ---------------------
nls_date_format DD-Mon-YY
1 row selected.
But I would not characterize this as "a problem"... it is a valuable feature that provides lots of flexibility in displaying and entering dates in Oracle-based applications.
For sure though, if developers don't understand how Oracle dates work and write code such as this:
-- BAD Coding
DECLARE
ld_holiday_date DATE;
BEGIN
-- Set a date type variable to a string value and
-- hope that Oracle can figure out what I mean.
ld_holiday_date := '01-JAN-2022';
END;
they are writing environment specific code which will definitely not work in another database (or session) that has a different NLS_DATE_FORMAT from the one they wrote their code in. Furthermore, the code above is having to do an implicit data type conversion (from string to date) which is leaving it up to Oracle to try and figure out what format is in the string.
To write more deterministic code with regard to Oracle dates, developers should definitely use the TO_DATE function. Here's the bullet proof version of the code snippet above:
-- Good Coding
DECLARE
ld_holiday_date DATE;
BEGIN
-- I do not care what the NLS date format is in this
-- database... this code will work everywhere.
ld_holiday_date := TO_DATE ('01-JAN-2022', 'DD-MON-YYYY');
END;

SQL: to_char alternative for Oracle AND SQL-Server

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

Dynamic SQL Query To_Date Format Oracle

I am using Oracle SQL Developer.
My tutor has asked us to include Dynamic Queries into our SQL statement.
Part of my query is this:
where booking.date_event != to_date('20140309','yyyymmdd') and booking.occassion_id=2
I have modified the query one step at a time to include the dynamic aspect. So it now looks like this:
where booking.date_event != to_date('20140309','yyyymmdd') and booking.occassion_id='&occassion_id'
This gives me the pop-up box to enter the ID correctly and it works correctly.
However, i now want to do the same for the date. But obviously entering a date in the format 'yyyymmdd' is not very user friendly.
How can i change my query to either allow for various types of date format or to add a message to the pop up box to inform the user to use the correct format? At the moment the pop up box only says "Date_Event" and an input box.
try to_date function. Here is some tips for to_date function.
http://www.dba-oracle.com/f_to_date.htm
SQL Developer is no tool for users. So you don't really have to worry about '20140309' format not being user friendly. For real users you would write a real app that accepts a date (with a calendar popup for instance) and sends it to the database in appropriate format.
However to have it a bit more convenient in SQL Developer, you could use to_date without format. Having set your environment and the database to the same locale, you could simply enter a date in the format you are used to (e.g. 9.3.13 or 09.03.2013 or March 9, 2013) and it should all work.

Convert Coldfusion Error.DateTime to a normal format?

At my company we store the information gathered from our site wide error template, into the database, but because of the format of the error.datetime it is making hard for me to do any sql queries for different date ranges.
Has anyone used some t-sql or coldfusion code to convert it to a mm/dd/yyyy format?
Here is an example of the format it currently is as.
Sun Jun 13 21:54:32 CDT 2010
But for any queries, I need to do, I have in a better format, I believe.
On the CF side, you should be able to user createOdbcDateTime() to correctly format it for the database or dateformat() to format it as text. If the date is coming back as text instead of a date object, you could use parseDateTime() to convert to a date object.
As an alternative, you could avoid having to convert dates at all if you just use the SQL Server built-in getDate() function to fill out your date column as the error is being inserted into the database.
It may not be exactly the same time (i.e. it might be out by a ms or 10) but it should be pretty close and perhaps good enough for your purposes.
Just make sure that your database server and application server are time synchronised!