Re: bizzare problem with to_number

"fabienne hadkova" <fh_at_q-bus.com> wrote in message news:aeeu13$jdq$1_at_news.imp.ch...
>
> > Looks like a disaster import from a disaster database. Anyone using a
> > varchar2 for number columns must be out of their minds.
> > Your export has been done using WE8ISO8859P1 and you are importing
> > (because you didn't set NLS_LANG) using the US7ASCII characterset, so
> > you will get character set conversion.
> > Also you will need to verify NLS_TERRITORY and NLS_NUMERIC_CHARACTERS
> > settings on those various disaster databases.
> > You are aware the to_char and to_number functions allow you to specify
> > NLS_* parameters?
> >
> > Hth
> >
> >
> > Sybrand Bakker, Senior Oracle DBA
>
> Hello, thanks for your answer
> It IS a disaster database and I am responsible for the disaster import
(just
> a beginner with oracle). Thanks, I'll redo the import setting NLS_LANG.
> Still, I don't really understand why the same column can have fields
> behaving differently, can this be because of the charachter set
conversion?
> But if yes, is it possible that the conversion would not be consistent?
> I am aware that those 2 functions allow to spcify NLS_* parameters only,
> since the format is diffenrent in the same column, I do have a problem in
> any case.
> Fabienne
>
>
>
>
>

I know of disaster situations were developers were relying on a default NLS_DATE_FORMAT. Unfortunately the NLS_DATE_FORMAT on the server was different from that on the clients. In this particular case the import failed completely as the table, which refused to import, was the master for all the rest.
My initial hunch is that the source database has been relying on specific NLS_ settings, but you have a point when you are referring to inconsistent data in one column. Without further analysis of the source database you will probably never know.

Regards

--
Sybrand Bakker
Senior Oracle DBA

to reply remove '-verwijderdit' from my e-mail address