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.
Related
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')
The SSRS report works fine if the user's date format is something like:
MM/dd/yyyy
But if the date format is different, the date parameter is "cleared out" automatically after being set, IT DISAPPEARS, for example, this fails
Again, if you put a value in that "End Date" parameter, it automatically disappears.
Things I have tried:
Setting the report's Language property to: "en-us", User!Language and blank.
So clearly SSRS thinks the date being input is invalid and it clears it out.
What do I need to do to make this work?
Possible workarounds
The following workarounds may solves this issue.
(1) Handling the parameters date format
If you do not want to edit all code, then it is easier to force the parameter data string format, make sure that all parameters passed to TO_DATE() function are in following format (or try to change the default date format from the OS regional settings):
dd-MMM-yyyy example: 01-AUG-2019
(2) Forcing Culture info by editing ReportViewer.aspx
You can edit the ReportViewer.aspx file is located in the SQL Server reporting services directory, and force the culture info used within reports. Check out the following question it will give you more details:
I want Datetime Parameter in DDMMYYYY Format in ssrs report
(3) Changing the browser language settings
Check the following link (read Mike Honey and Nick St Mags answers):
SSRS Datetime Parameter value should display in DD/MM/YYYY format
You can check the following answer, it contains many workarounds that may give you some insights:
Oracle Date format exception in SQL Server Reporting Services
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;
The problem in short: The same database returns dates in a different format on different servers and I'm having trouble to configure it to correct date format.
I have the following situation:
A PHP-based web application that gets it's data from Microsoft FoxPro 9 databases.
The database connection is made with OleDB. In PHP this utilises ADODB through COM objects:
$this->connection = new COM("ADODB.Connection");
$this->connection->Open($this->connectionString);
The connection string looks like this:
Provider=VFPOLEDB.1; Mode=Share Deny None; Window Handle=0;
Locale Identifier=1033; Prompt=4; Extended Properties=0;
User ID=; Password=; Mask Password=False; Cache Authentication=False;
Encrypt Password=False; OLE DB Services=0; Collating Sequence=MACHINE; DSN=;
DELETED=True; ENGINEBEHAVIOR=80; TABLEVALIDATE=0;
Data Source=\\path\to\file.DBC
The program is deployed on different servers throughout the world, running on different versions of Windows Server (2003-2008 R2). Query's are executed the following way:
$this->connection->Execute($query);
This returns a resultset with all values in plaintext. This is where the problem arises. The databases don't use the same formatting for dates, which makes it difficult to process the dates later on in PHP.
So far, the app can cope with the US format: mm/dd/yyyy and the dutch format: dd-mm-yyyy. The program just assumes that when the date contains slashes the US format is used and when there are hyphens the d-m-y format is used.
This has been going fine for a long time, but now we recently deployed the program to a server in Brazil, which returns dates in the Brazilian format dd/mm/yyyy. The program obviously now confuses this with the US format.
I've been trying to get the database to report in a different date format (US) to no avail.
On two different dev-environments, changing the Regional settings of windows to a different country immediately alters the date-format the database uses. These dev-environments are all Windows 7 systems.
However, this won't work on the servers with Windows Server. I have changed around all of the Regional settings (Formats, Location and System locale) on multiple servers without any results. Even after rebooting or reïnstalling FoxPro with the correct regional settings. The databases keep reporting in the date-format they seem stuck in.
Does anybody know how I can change the date-format used by FoxPro on a Windows Server environment?
Other options I have explored include putting regional information into the DSN, but couldn't I find any possible way. Also the FoxPro statement SET DATE TO ..... is not accepted through OleDB.
Altering the application to understand the Brazilian format or to add a bunch of if-else statements doesn't seem like a feasible solution.
The FoxPro date type is date-format-insensitive. That is, if you simply return the value as a date (datetime) rather than converting to character, you shouldn't have any problems.
Wrap your FoxPro date field the DTOC function, with the second optional parameter. This will return a standard YYYY-MM-DD style date, regardless of regional setting.
SELECT DTOC(dDate) as dDate FROM Alias
If that's not feasible, you'll need to investigate the functions to explicitly set a locale in FoxPro, such as the intuitively named SYS(3005).
And if even that's not feasible, you'll need to resort to requiring servers in foreign countries to have their regional settings standardized at the OS level.
Maybe be explicit in your query and handle reconstructing the date within the web application. So if you have a date-type field in VFP called MyDate then do:
select x, y, z, day(MyDate) as daynum, month(MyDate) as monthnum, ;
year(MyDate) as yearnum from mytable
OK, so it's more work on the other reconstructing a date from that but at least it should be location-agnostic.
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!