Brian Peasland schrieb:
> Luch wrote:
>> On Feb 28, 2:28 pm, Brian Peasland <d..._at_nospam.peasland.net> wrote:
>>> Since this is in development, does it really matter if their activity is
>>> "off"? They aren't working on real data anyway.
>>
>> Yes, it does... What I mean is that the developer uses SYSDate, and
>> doesn't notice any problem. When our program is deployed to customers,
>> the sysdate function call is still there (instead of the one he
>> should've been using) and the customer sees the error. Of course the
>> real solution is the programmer should be calling our own function to
>> return the current datetime instead of using sysdate. I want to block
>> them from using sysdate.
>>
>>
>>> Have you thought about setting their session's timezone?
>>>
>>> ALTER SESSION SET TIME_ZONE= '[+|-]hh:mm'
>>> | time_zone_region
>>>
>>> The data may be stored in the database's local time zone, but the
>>> session can do a conversion as it is working with the data.
>>>
>>
>> So if this is done when the session is established, and a call to
>> sysdate is done, it will return the current datetime in the timezone I
>> manipulate it to return it as?
>>
>>
>
> Yes.
>
> This way, Oracle handles the timezone differences and you do not have to
> worry about coding your own functions.
>
> HTH,
> Brian
>
Brian, you mean probably the CURRENT_DATE, not the SYSDATE.
Best regards
Maxim
Received on Wed Feb 28 2007 - 16:02:47 CST
