This content has been marked as final. Show 11 replies
I've seen this problem when shp2sdo is run on one platform (windows) and loaded on another platform (unix) without running dos2unix or going through ftp.
Also, i've seen it when there is a problem between character sets - shp2sdo generates data in us ascii format. If this is the problem:
On a WINDOWS NT/2000/XP system, fix it by setting the NLS_LANG registry entry for the Oracle Home to: AMERICAN_AMERICA.WE8ISO8859P1. On UNIX systems, the Oracle initialization parameters can be set as follows:
Hope one fo these fixes it.
Hmmmm, another problem :(
Some columns of type NUMBER appear to have negative numbers for all rows in the created table and the positive value of these numbers are not the same as they are in the .dbf-file. If the latter was true, then I could easily fix this by multiplying the columns by -1.
It looks like this only happens with 'big' numbers in the .dbf-file. There must happen a conversion somewhere, since all the values for that particular column in the table are distinct, so the reader/oracle is able the handle/read 'big' numbers. (select distinct(id) from ... == #rows in .dbf)
For example: 10560001587671 (in .dbf) becomes -1322993193 (in table).
Is this a known problem?
thanks a lot,
When I open the .dbf file in MS Excel, the values are 'big' and positive (10560001587671), but when I select the same columns in the oracle dbase, the values are 'small' and negative (-1322993193). I suppose something goes wrong while loading the .shp/.dbf into the database.
Can you please send me a mail at 88058_AT_clueless.be (this mail is correct, I made a forward to avoid future spam), so I can send you an example of files where it goes wrong.
Maybe it has something to do with the NLS_LANG registry setting, which I had to set to AMERICAN_AMERICA.WE8ISO8859P1 (see above)?
Thanks a lot Dan,
I'm having the same problem! This is an incredible bug.
In my case:
0. I have in shapefiles some ID's fields (for identify each tables or join to some other) with 12 or 14 digit length (NUMBER type).
1. I correctly exported data from shp to different files with shp2sdo utility.
2. When I open .dat file I realised ID's values are completely different and shorter than It must to do.
3. If I import all data to Oracle DB, data and ID's values are still shorter than would be.
Ex: Original ID: 17240034001163
After shp2sdo in .dat: 35275019
I was looking for a solution but I did not have not found!!
Could you share your "converter with a potential fix" for that bug?