Re: date problem

On Thu, 25 Jan 2007 10:15:39 -0800, DA Morgan <damorgan_at_psoug.org> wrote:

>Jeff Kish wrote:
>> Hi.
>> I have some software (really old stuff) I maintain.
>> It never had any internationalization or anything (its really old).
>> It runs on windows and interfaces with a database (in this case Oracle) via a
>> 3rd party "c++" accessible library.
>>
>> Recently an install happened in a Spanish speaking country.
>>
>> It seems that some record inserts were failing with the message:
>>
>> a non numeric character was found where a numeric was expected
>> This query I believe reveals the character set:
>>
>> SQL> select SYS.PROPS$.VALUE$ from SYS.PROPS$ where ((SYS.PROPS$.NAME =
>> 'NLS_CHARACTERSET'));
>>
>> VALUE$
>> -------------------------
>> WE8ISO8859P1
>>
>> I believe the basic embedded sql which has not failed in the past used this
>> sql:
>>
>> INSERT INTO table( id, newpass, thedate )VALUES ( :userid, :pswd,
>> TO_DATE( :thedate, 'DY MON DD HH24:MI:SS YYYY' ) )
>>
>> Note the colons prefix names used to bind values in the embedded system.
>>
>> I thought the TO_DATE would 'fix' things up properly.. I'm not sure how to
>> analyze the problem to determine the cause.
>>
>> Thanks for any suggestions,
>>
>> Jeff Kish
>
>Verify character sets and NLS properties.
>
>ALTER SYSTEM as is appropriate.
>
>Also, verify the database version, is compatible. When you say "old" I
>ask "how old?"

I'm waiting for an answer to the "old" question.

How do I verify the character and NLS properties past the query already done for the character set?

I'm not sure we can do any 'alter system' as it might alter the customers system which has other things running on it. (I'm studying and trying to understand).

thanks
Jeff Kish Received on Thu Jan 25 2007 - 12:51:05 CST