Members   Search   Help    Register    Login   Home
Home » SQL & PL/SQL » SQL & PL/SQL » Date Format (10.2.0.2.0 ,windows)
Date Format [message #429694] Thu, 05 November 2009 04:51 Go to next message
Hitman11
Messages: 60
Registered: October 2009
Location: norway
Member
Hi all,

Can anybody explain the purpose of defining DATE FORMAT MASK at session and
database level and is it necessary that it has to be defined in database/session
for any transaction that is executed?


Thanks
Report message to a moderator
Re: Date Format [message #429696 is a reply to message #429694] Thu, 05 November 2009 05:26 Go to previous messageGo to next message
Michel Cadot
Messages: 29435
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
The purpose is to have a default format at database/session level.
The good practice is to NEVER use the default format.

Regards
Michel
Report message to a moderator
Re: Date Format [message #429699 is a reply to message #429696] Thu, 05 November 2009 05:30 Go to previous messageGo to next message
pablolee
Messages: 1672
Registered: May 2007
Location: Scotland
Senior Member
Quote:
The good practice is to NEVER use the default format.

I assume that you mean never use the default format in the context of never rely on implicit conversion.
Report message to a moderator
Re: Date Format [message #429705 is a reply to message #429699] Thu, 05 November 2009 05:39 Go to previous messageGo to next message
Michel Cadot
Messages: 29435
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
pablolee wrote on Thu, 05 November 2009 12:30
Quote:
The good practice is to NEVER use the default format.

I assume that you mean never use the default format in the context of never rely on implicit conversion.

Yes, this was what I meant.
You can (and maybe would) use default format to return/display dates.

Regards
Michel
Report message to a moderator
Re: Date Format [message #429706 is a reply to message #429705] Thu, 05 November 2009 05:39 Go to previous messageGo to next message
pablolee
Messages: 1672
Registered: May 2007
Location: Scotland
Senior Member
Agreed, just felt it needed clarification (I'm easily confused you know Wink )
Report message to a moderator
Re: Date Format [message #429747 is a reply to message #429705] Thu, 05 November 2009 11:30 Go to previous messageGo to next message
Hitman11
Messages: 60
Registered: October 2009
Location: norway
Member


"never rely on implicit conversion"

May i know why we should never rely on implicit conversion?

Regards,
Report message to a moderator
Re: Date Format [message #429748 is a reply to message #429747] Thu, 05 November 2009 11:37 Go to previous messageGo to next message
BlackSwan
Messages: 3359
Registered: January 2009
Senior Member
>May i know why we should never rely on implicit conversion?

Code that depends/relies on implicit conversion will fail
when current default format does not match previous default format.
Report message to a moderator
Re: Date Format [message #429752 is a reply to message #429747] Thu, 05 November 2009 11:57 Go to previous messageGo to next message
BlackSwan
Messages: 3359
Registered: January 2009
Senior Member
>>May i know why we should never rely on implicit conversion?

Using implicit conversion which date is '07/08/09'?
Report message to a moderator
Re: Date Format [message #429793 is a reply to message #429747] Thu, 05 November 2009 16:49 Go to previous messageGo to next message
JRowbottom
Messages: 5368
Registered: June 2006
Location: Sunny North Yorkshire, ho...
Senior Member
Quote:
May i know why we should never rely on implicit conversion?


Because you cannot guarantee that the default date format mask won't change.
Report message to a moderator
Re: Date Format [message #429944 is a reply to message #429748] Fri, 06 November 2009 07:41 Go to previous messageGo to next message
Hitman11
Messages: 60
Registered: October 2009
Location: norway
Member
Say for example ,when im inserting,updating ,deleting data in database, i should change
the date format rather than the default date format else the application code
would change and result in problem.

Is this what you guys mean ?

Please confirm.


Regards,
Report message to a moderator
Re: Date Format [message #429945 is a reply to message #429944] Fri, 06 November 2009 07:43 Go to previous messageGo to next message
Frank
Messages: 7317
Registered: March 2000
Senior Member
Sorry, misread your question...

You should always use explicit date-formats when inserting, deleting, updating and selecting, etc.
That way, you don;t have to mess with the session format.

[Updated on: Fri, 06 November 2009 07:45]

Report message to a moderator
Re: Date Format [message #429960 is a reply to message #429944] Fri, 06 November 2009 09:08 Go to previous messageGo to next message
JRowbottom
Messages: 5368
Registered: June 2006
Location: Sunny North Yorkshire, ho...
Senior Member
Every time you do a TO_DATE or TO_CHAR of a date, you should specify the format mask that you wish to be used.

If there is any possibility of your code being used in more than one country, you should give serious consideration to specifying the optional nlsparam value that determines the language that will be used
Report message to a moderator
Re: Date Format [message #429986 is a reply to message #429747] Fri, 06 November 2009 12:39 Go to previous message
joy_division
Messages: 2884
Registered: February 2005
Location: NY
Senior Member
Hitman11 wrote on Thu, 05 November 2009 12:30


"never rely on implicit conversion"

May i know why we should never rely on implicit conversion?


Boy, you really seem to ask pretty odd questions that going against common logic.

Wasn't it you who asked why it is bad to have invalid objects in the database?
Report message to a moderator
Previous Topic:looking for sql script guru.
Next Topic:ora-01779 :cannot modify a column which maps to a non key- preserved table
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Dec 1 06:48:21 CST 2009

Total time taken to generate the page: 0.34103 seconds
.:: Forum Home :: Blogger Home :: Wiki Home :: Contact :: Privacy ::.