【问题标题】:Incorrect DECIMAL value when inserting MySQL插入 MySQL 时 DECIMAL 值不正确
【发布时间】:2017-03-31 11:58:56
【问题描述】:

我得到的错误是:

ERROR 1366 (HY000): DECIMAL value 不正确: '0' for column '' at row -1

我正在尝试normalize 数据库并确保数据类型正确。将来自BASE_TABLE 的数据插入到名为Inventors 的新表中。

这是我用来插入的查询。如果我从select 查询中手动获取一行,它可以正确插入到 Inventors 表中。

但是,像这样运行查询我立即得到上述错误。

INSERT INTO
    Inventors(ID,Firstname,Middlename,Lastname,Country,Latitude,Longitude)
SELECT DISTINCT
    Inventor_ID as ID,
    Firstname,
    Middlename,
    Lastname,
    Country,
    cast(Latitude as decimal(11,6)) as Latitude,
    cast(Longitude as decimal(11,6)) as Longitude
FROM
    BASE_TABLE

这是在select 查询中插入失败的行:

ID          Firstname   Middlename  Lastname    Country     Latitude    Longitude
04308666-3  RICHARD     RICHARD     JUNG                    0.000000    0.000000

Inventors创建查询:

CREATE TABLE `Inventors` (
  `ID` varchar(55) NOT NULL DEFAULT '',
  `Firstname` varchar(255) DEFAULT NULL,
  `Middlename` varchar(255) DEFAULT NULL,
  `Lastname` varchar(255) DEFAULT NULL,
  `Country` varchar(255) DEFAULT NULL,
  `Latitude` decimal(11,8) DEFAULT NULL,
  `Longitude` decimal(11,8) DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

BASE_TABLE创建查询:

CREATE TABLE `BASE_TABLE` (
  `Firstname` varchar(255) DEFAULT NULL,
  `Middlename` varchar(255) DEFAULT NULL,
  `Lastname` varchar(255) DEFAULT NULL,
  `Country` varchar(255) DEFAULT NULL,
  `Zipcode` varchar(255) DEFAULT NULL,
  `Latitude` varchar(255) DEFAULT NULL,
  `Longitude` varchar(255) DEFAULT NULL,
  `InvSeq` int(11) DEFAULT NULL,
  `Patent` varchar(255) DEFAULT NULL,
  `AppYear` year(4) DEFAULT NULL,
  `ApplyYear` year(4) DEFAULT NULL,
  `PubYear` year(4) NOT NULL,
  `AppDate` varchar(255) DEFAULT NULL,
  `Assignee` varchar(255) DEFAULT NULL,
  `AsgNum` varchar(255) DEFAULT NULL,
  `Class` varchar(255) DEFAULT NULL,
  `Coauthor` varchar(255) DEFAULT NULL,
  `Invnum` varchar(255) DEFAULT NULL,
  `Invnum_N` varchar(255) DEFAULT NULL,
  `Record_ID` varchar(255) NOT NULL,
  `Inventor_ID` varchar(255) DEFAULT NULL,
  `Match_Level` tinyint(4) DEFAULT NULL,
  `Company_ID` varchar(255) DEFAULT NULL,
  `Classification` varchar(255) DEFAULT NULL,
  `Citing` mediumint(9) DEFAULT NULL,
  `Cited` mediumint(9) DEFAULT NULL,
  PRIMARY KEY (`Record_ID`),
  KEY `Inventor_ID` (`Inventor_ID`),
  KEY `Patent` (`Patent`),
  KEY `Patent_2` (`Patent`,`Inventor_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

谁能帮我解决这个问题?

【问题讨论】:

  • 显然cast() 不起作用。您需要查看这些列中的值。
  • 请查看编辑后的帖子。我从select 查询中添加了三个值。
  • 。 .只需要一个值就会失败,您就会得到该错误。
  • 查看字段 Longitude 是否在目标表中设置为无符号
  • ...请尝试始终发布 CREATE TABLE 和 INSERT 脚本,以便更轻松地为您提供帮助。

标签: mysql database-normalization


【解决方案1】:

我发现了问题。 Latitude (VARCHAR)BASE_TABLE 中的 Longitude (VARCHAR) 具有空字符串 '' 的值。由于某种原因,这导致 MySQL 转换为不正确的值。

我通过在选择查询中将空字符串替换为NULL 解决了这个问题(见下文)。

INSERT INTO
    Inventors
SELECT DISTINCT
    Inventor_ID as ID,
    Firstname,
    Middlename,
    Lastname,
    Country,
    IF(Latitude='',NULL,CAST(Latitude as decimal(11,6))) as Latitude,
    IF(Longitude='',NULL,CAST(Longitude as decimal(11,6))) as Longitude
FROM
    BASE_TABLE

【讨论】:

  • “出于某种原因”? ''是什么十进制数字?
  • 是的@philipxy,由于某种原因,当接收到空字符串时,cast 函数返回 0.000000 而不是空字符串。但由于某种原因,它仍然无法保存它,尽管 0.000000 是小数,我想。
  • 为什么 cast 在给定一个字符串时会返回一个空字符串? spec 表示传递一个字符串,该字符串是指定类型的表达式。空字符串不是数字表达式。所以你得到了一个错误。
  • 很公平。只是觉得奇怪的是,当专门运行select 查询时,cast 函数在接收到空字符串时不会失败,而是返回值0.000000。在 select 查询期间没有失败,但在沿着 insert 查询运行时实际上失败了,这使得它在 imo 中非常模棱两可。
  • 您还没有说明“从选择查询中手动获取单行”和“当接收到空字符串并返回值 0.000000 时”的意思,或者您认为它“确实如此”的原因不会失败”。
【解决方案2】:

我会将此添加为评论,但没有所需的代表,因此对此我深表歉意。

我遇到了与 Philip 完全相同的问题和行为。

为了回答 philipxy(现年 1.75 岁)的问题,Philip 的意思是:

  1. 当 SELECT 语句自行执行时,它不会出现任何错误 - CAST 成功将空字符串 ('') 转换为 0.000000 并反映了这一点在查询结果集中。
  2. 当 SELECT 语句作为包含 INSERT INTO 语句的一部分执行时,CAST 无法将完全相同的空字符串转换为十进制值,并出现错误 1366。

这就是他正确地称之为“模棱两可”的原因,因为 CAST 在这两个不同的用例中的工作方式不同,这充其量是令人困惑的。奇怪的是错误消息不包含列名并且该行被列为 -1。

我认为这里可能有一个错误需要解决,因为无论场景如何,CAST 都应该以相同的方式工作。

幸运的是,菲利普自己的答案也对我有用,所以谢谢菲利普!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-09-30
    • 2021-11-16
    • 2019-12-13
    • 1970-01-01
    • 2023-01-18
    • 1970-01-01
    • 2019-11-16
    相关资源
    最近更新 更多