数据列中的Oracle 2连字符?
副问题[/!--empirenews.page--]
我有一个Oracle表(版本8i),我必要迁徙到sql server,个中一列是NUMBER数据范例.在个中,它具有如下值: --1331013400000000000000000000 --1331017903617177360300000000 --1331012863048235233700000000 等等 0.9574875526618150 2.51572327044025 – 看起来像存储在数字列中的现实值.我不大白破折号是什么或它们意味着什么,可是,当我实行通过ssma迁徙数据时,我获得“无法将字符串值放入浮点数”,以是很明明sql server在这种环境下会碰着贫困,由于我做. 我敢必定我可以找到一种要领来处理赏罚这些稀疏的数据,我只是想知道这意味着什么,它是什么,我用谷歌搜刮,但令人惊奇的是白手而归.有人有任何线索吗? 转储1016: 0.2722718362012630 Typ=2 Len=9: c0,1c,17,48,54,3f,2,1b,1f --1331013400000000000000000000 Typ=2 Len=4: 32,ea,43 0.50761421319797 Typ=2 Len=8: c0,33,4d,f,16,20,62,62 1 Typ=2 Len=2: c1,2 0.9574875526618150 Typ=2 Len=9: c0,60,4b,58,38,3e,52,33 1.11894371713103 Typ=2 Len=9: c1,c,5a,2c,4 2.51572327044025 Typ=2 Len=9: c1,3,34,3a,18,5,29,1a 0.0537258905066351 Typ=2 Len=9: c0,6,26,1a,7,40,34 0.1851303317535540 Typ=2 Len=9: c0,13,1f,22,12,36,29 0.0000000000000000000000000000306386 Typ=2 Len=4: b2,57 1.6164 Typ=2 Len=4: c1,41 0.1289839930864580 Typ=2 Len=9: c0,d,64,57,2e,51 0.004721435316336170 Typ=2 Len=9: bf,30,11,47 --1331017903617177360300000000 Typ=2 Len=10: 32,28,1e,41,62 --1331012863048235233700000000 Typ=2 Len=10: 32,49,61,42,4e,40 --1331010715609612880500000000 Typ=2 Len=10: 32,5e,56,59,60 0.0778391842453491 Typ=2 Len=9: c0,8,4f,2b,23,5c --1331010187793684447000000000 Typ=2 Len=10: 32,e,39,1f 0.8296 Typ=2 Len=3: c0,53,61 --1331015225486314961400000000 Typ=2 Len=10: 32,31,4c,35,57 --1331016035469906437500000000 Typ=2 Len=10: 32,37,5f,1a 0.3301637612255680 Typ=2 Len=9: c0,51 0.2666453350398630 Typ=2 Len=9: c0,43,1f 0.1581527755812110 Typ=2 Len=9: c0,10,b 0.8089305937550560 Typ=2 Len=9: c0,51,3c,3d --1331015006297067350000000000 Typ=2 Len=9: 32,42 0.3745318352059930 Typ=2 Len=9: c0,1f --1331017625157985988000000000 Typ=2 Len=10: 32,19,15 更新: 这是统计计较库中的一个错误.在某些前提下,返回Doubles的函数在计较sdev时获取sqrt时会天生NaN值.在预筹备语句结构中行使的Oracle驱动措施(oracle14.zip)不验证数据,而是发送和写入原始字节,这最终导致破坏.风趣的是,当我试图在筹备语句中配置一个NaN值时,MS SQL Server驱动措施不应承我建造一个筹备好的语句并激发非常.宣布这个就像“fyi”…… 办理要领它没有任何意义,它不是’为’任何对象;我担忧你的数据是糜烂的. – 是表中的现实值,但它不是数字. Oracle的内部数字暗示在注释1031902.6中有所涉及,假如你有权会见它,可能 this explains it if you don’t.假如它真的是负数,那么最后的十六进制字节应该是66.倾倒它看起来的数字 – 用一个减号,不是两个,这是毫有时义的 – 给出:select dump(-1331013400000000000000000000,1016) from dual; DUMP(-1331013400000000000000000000,1016) ---------------------------------------- Typ=2 Len=6: 31,46,66 在Oracle中建设无效数字并不简朴(我想您不会祈望它),但这是我早年行使过的要领.个中一条线索,除了双减号以及它们都是沟通的长度之外,将转储后的值转换回数字并不会发生沟通的功效: create table t42(value number); declare n number; begin dbms_stats.convert_raw_value('32ea004366',n); insert into t42 (value) values (n); end; / select value from t42; VALUE -------------------------------------- -<3:13400000000000000000000 这是来自Oracle 9i,我此刻封锁到8i数据库,以是功效也许会有所差异. 虽然,不能做to_number(值)也是一个很大的线索;当你这样做时有一个隐含的to_char(),以是它试图将文本暗示转换为数字,这表明白错误.风趣的是,to_char()值与简朴选择的值不匹配.假如您对数据执行了沟通的操纵,则会看到沟通的错误. select to_number(value) from t42; select to_number(value) from t42 * ERROR at line 1: ORA-01722: invalid number select to_char(value) from t42; TO_CHAR(VALUE) ---------------------------------------- -`003400000000000000000000 除非您知道坏数据的来历并保存原始数据,不然您也许无法拯救这些值.我以为你能做的最好就是忽略它,可能用可以迁徙的对象替代它 – 假如字段可觉得空,那么null将是安详选项,不然我猜你必需选择一个神奇的值. 辨认和修改受影响的行可以通过函数完成;也许是这样的: create or replace function null_bad_number(value number) return number deterministic as tmp_value number; invalid_number exception; pragma exception_init(invalid_number,-1722); begin select to_number(value) into tmp_value from dual; return value; exception when invalid_number then return null; end; / 行使先前建设的沟通无效值和一个有用值: insert into t42 (value) values (0.9574875526618150); select * from t42; VALUE ---------- -`.003E+24 .957487553 update t42 set value = null where value is not null and null_bad_number(value) is null; 1 row updated. select * from t42; VALUE ---------- .957487553 无论怎样都不抱负,但在这一点上,我以为你只是在拯救你所能做到的.您可以删除行而不是更新它们,可能将值配置为其他值,这取决于您但愿怎样继承. (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |