ORA-00932: 数据类型不一致: 应为 -, 但却获得 –

本文介绍了在Oracle数据库中因游标读取列数不匹配导致的错误,并演示了如何定位及解决此类问题。通过创建测试表和过程,展示了不同情况下编译与运行时可能出现的错误。

    错误发生的原因是在执行存储过程操作中,读取游标少读取了某个或者某些列。

         不过,这似乎是不可能发生的,因为编译阶段都会报错。

         下面演示错误的发生以及解决方法。

         1.创建测试表USERS

         CREATE TABLE "USERS2" (

     "USERNAME" VARCHAR2(20 BYTE),

         "USERPASS" VARCHAR2(20 BYTE),

         "COUNTER" NUMBER(11,0)

) ;

2.创建测试过程PROC_DEMO,故意少读取一列。

create or replace

PROCEDURE PROC_DEMO AS

uname varchar2(20);

upass varchar2(20);

counter number;

BEGIN

  DECLARE CURSOR CUR_USERS is

        select * from  USERS;

  BEGIN

    OPEN CUR_USERS;

    LOOP

    FETCH CUR_USERS INTO uname,upass;

      EXIT when CUR_USERS%NOTFOUND;

       dbms_output.put_line('uname:'||uname);

       dbms_output.put_line('upass:'||upass);

       dbms_output.put_line('counter:'||counter);

    END LOOP;

    CLOSE CUR_USERS;

  END;

END PROC_DEMO;

 

编译以上过程,发生错误:

Error(12,5): PL/SQL: SQL Statement ignored

Error(12,5): PLS-00394: FETCH 语句的 INTO 列表中值数量出现错误

 

连编译都通不过,更不要说在执行时出现如下错误:ORA-00932: 数据类型不一致: 应为 -, 但却获得

 

以上是在SQL Developer进行的测试。在PROC_DEMO声明游标CUR_USERS并读取,如果少读取了某个或者某些列编译通不过。如果游标CUR_USERS不是在过程中显示声明的而是通过调用返回游标类型数据的过程中获取的,那么少读取了某个或者某些列编译可能能够通过。

3.创建返回游标和基本类型数据的过程。

该过程封装在包中,包声明如下:

create or replace PACKAGE PACKAGE_TEST AS

  TYPE CURSOR_TYPE IS REF CURSOR;

  PROCEDURE PROC_TEST(

  COUNTER OUT NUMBER,

  CUR_USERS OUT CURSOR_TYPE

  );

  END PACKAGE_TEST;

创建包体如下:

create or replace PACKAGE BODY PACKAGE_TEST

IS

  PROCEDURE PROC_TEST(

    COUNTER OUT NUMBER,

    CUR_USERS OUT CURSOR_TYPE

  )

  IS

  SELECT_SQL VARCHAR2(200);

  BEGIN

  SELECT_SQL := 'SELECT COUNT(*)  FROM USERS';

  EXECUTE IMMEDIATE SELECT_SQL INTO COUNTER;

  SELECT_SQL := 'SELECT USERNAME,USERPASS FROM USERS';

  OPEN CUR_USERS FOR SELECT_SQL;

  END PROC_TEST;

END PACKAGE_TEST;

 4.创建测试过程PROC_CLIENT

create or replace

PROCEDURE PROC_CLIENT AS

TYPE CURSOR_TYPE IS REF CURSOR;

CUR_USERS CURSOR_TYPE;

COUNTER number;

uname varchar2(20);

upass varchar2(20);

BEGIN

    --调用PACKAGE_TEST中的过程PROC_TEST

    PACKAGE_TEST.PROC_TEST(COUNTER,CUR_USERS);

    --打印结果信息

    DBMS_OUTPUT.PUT_LINE('COUNTER:'||COUNTER);

    DBMS_OUTPUT.PUT_LINE('返回的游标中的数据:');

    LOOP

    FETCH CUR_USERS INTO uname;

      EXIT when CUR_USERS%NOTFOUND;

       dbms_output.put_line('uname:'||uname);

       --dbms_output.put_line('upass:'||upass);

    END LOOP;

    CLOSE CUR_USERS;

END PROC_CLIENT;

 

运行PROC_CLIENT,发生如下错误:

ORA-00932: 数据类型不一致: 应为 -, 但却获得 -

ORA-06512: "DEMO.PROC_CLIENT", line 14

ORA-06512: line 2

 

原因是PACKAGE_TEST.PROC_TEST返回的游标CUR_USERS是表USERS两个列

USERNAMEUSERPASS的结果集,但是在PROC_CLIENT中读取该游标时只读取了USERNAME

解决方法:

将读取游标的语句修改为如下所示:

FETCH CUR_USERS INTO uname,userpass;

      EXIT when CUR_USERS%NOTFOUND;

       dbms_output.put_line('uname:'||uname);

       dbms_output.put_line('upass:'||upass);

总结,通过上面的演示可以发现其实这是个很表面的错误,仅仅因为游标是从别的过程中声明并产生数据集的,所以躲过了很多编译错误,直到运行时才发生莫名其妙的错误。

ORA-00932 错误通常表示在 SQL 语句中出现了数据类型匹配的问题,以下是一些常见的解决方法: ### 检查 SELECT 语句 在使用 `SELECT` 语句时,如果使用了 `UNION`、`UNION ALL`、`INTERSECT` 或 `MINUS` 操作符,要求各查询结果的列数和对应列的数据类型必须一致。例如: ```sql -- 错误示例 SELECT column1 FROM table1 UNION SELECT column2 FROM table2; -- 假设 column1 是 NUMBER 类型,column2 是 VARCHAR2 类型,需要将其转换为相同类型 SELECT TO_CHAR(column1) FROM table1 UNION SELECT column2 FROM table2; ``` ### 检查 INSERT 语句 在使用 `INSERT` 语句时,插入的值的数据类型必须与表中对应列的数据类型一致。例如: ```sql -- 错误示例 INSERT INTO table_name (column1) VALUES ('abc'); -- 假设 column1 是 NUMBER 类型,需要插入正确的数字 INSERT INTO table_name (column1) VALUES (123); ``` ### 检查函数和操作符的使用 某些函数和操作符对数据类型有特定的要求,若满足要求会导致数据类型一致错误。例如,进行数值运算时,操作数必须是数值类型。 ```sql -- 错误示例 SELECT '123' + 456 FROM dual; -- 需要将字符串转换为数值类型 SELECT TO_NUMBER('123') + 456 FROM dual; ``` ### 检查连接条件 在使用 `JOIN` 操作时,连接条件中的列的数据类型需要一致。 ```sql -- 错误示例 SELECT * FROM table1 JOIN table2 ON table1.column1 = TO_CHAR(table2.column2); -- 确保数据类型一致 SELECT * FROM table1 JOIN table2 ON table1.column1 = table2.column2; ```
<think>首先需要根据系统指令组织回答: 1. 所有行内数学表达式必须使用$...$格式(但本问题涉及数学表达式)。 2. 独立公式使用$$...$$格式,但本问题无数学公式。 3. LaTeX语法正确:确保误用。 4. 使用中文回答。 5. 生成相关问题。 6. 引用的段落末尾自然添加引用标识[^n]。 用户查询:解决Oracle还原数据时出现ORA-00910错误(指定的长度对于数据类型而言过长)的问题。参考引用[1]和[^2]。 引用内容: - [^1]:描述了IMP导入时出错,ORA-00910在创建表时发生,具体是字段定义如NVARCHAR2(500)等。 - [^2]:官方说明数据类型如VARCHAR2(size [BYTE | CHAR])等。 分析错误:ORA-00910意味着在定义字段时,长度超过了该数据类型的最大允许长度。例如,在Oracle中,某些数据类型的长度是有限的。比如: - VARCHAR2的最大长度是4000 BYTES或CHAR(取决于设置)。 - 如果是UTF-8编码,字符数可能由于多字节字符而少于字节数。 从引用[1]看,创建表T_CSL_DYNAITEMDATAENTRY时,有字段如NVARCHAR2(500),这在Oracle中应该没问题,因为NVARCHAR2最大允许4000字符或32767字节,取决于版本(例如,12c及以上支持更大长度)。ORA-00910可能意味着某个字段的长度定义超出了限制。 但在错误信息中,字段定义如"FVALUETYPE" NUMBER etc.,看起来正常。注意错误消息有断行和引号问题,可能是一个字段定义错误。 仔细看引用[1]: - "FKEYNUMBER" NVARCHAR2(500) NOT NULL ENABLE, - "FTEXTVALUE" NVARCHAR2(4000), – 这应该接近最大。 在Oracle中: - VARCHAR2最多4000 BYTES(在12c前)。 - NVARCHAR2最多4000字符或2000字节(取决于版本和设置),但在12c及以上支持32767字节。 用户提到“还原数据”,可能是在IMP导入时发生。错误出现在创建表语句中。 原因分析: - 最常见的问题是当使用多字节字符集时,如果定义了VARCHAR2(size CHAR)但没有指定正确大小,或总长度超过限制。 - 另一个可能性是表空间或数据库参数设置对,但ORA-00910明确指出是数据类型长度问题。 从引用[2]: - 数据类型定义如CHAR(size), VARCHAR2(size), etc. size must be within limits. 解决步骤: 1. **检查表定义错误**:在创建表语句中,某个字段的数据类型长度定义超过了Oracle的允许范围。例如,NVARCHAR2(size), size 必须 <= 4000 for pre-12c. In 12c or later, it can be up to 32767 if MAX_STRING_SIZE=EXTENDED. 2. **检查数据库设置**:如果Oracle数据库参数 MAX_STRING_SIZE 是STANDARD,则最大大小是4000字节。如果是EXTENDED,则支持更大。 3. **调整大小或参数**:修改表定义,将过大长度调整为适当值,或更改数据库参数。 具体解决方案: - **对于NVARCHAR2(500)**:500 应该是可接受的,因为标准最大值为4000字符?等一下,NVARCHAR2存储Unicode,每个字符最多4字节(UTF-8),所以500 * 4 = 2000字节,应在4000以内。但也许其他字段有问题。 再查错误语句: - "FVALUETYPE" NUMBER(10, 0) – 这涉及长度问题。 - "FTEXTVALUE" NVARCHAR2(4000) – 这是边界。但NVARCHAR2(4000)应该没问题,除非大小超过。 - 关键在于错误可能在字段定义中,但消息显示“specified length too long”,所以可能NVARCHAR2(4000)在某些上下文中无效? 或导入文件有误。 在Oracle 11g及以前,NVARCHAR2最大 size 是2000字符,因为它存储每个字符2字节(AL16UTF16),最多4000字节的字符串大小。4000字符会导致 max size exceeded。Oracle Database 12c introduced 扩展。 错误消息中: - "FTEXTVALUE" NVARCHAR2(4000) – 如果在11g,4000 可能超过2000字符限制?AL16UTF16中每个字符2字节,所以4000字符是8000字节,超过最大值。最大NVARCHAR2大小是2000字符(4000字节)在11g and earlier for VARCHAR2 and NVARCHAR2 in terms of bytes for the maximum length. 在Oracle 11g: - VARCHAR2:最大4000 BYTES - NVARCHAR2:最大2000 CHARACTERS,因为每个字符最多使用2字节。 如果NVARCHAR2(4000)定义使用,在11g中会报错 ORA-00910 because 4000 characters > 2000 max characters for NVARCHAR2. 在12c及以上, with MAX_STRING_SIZE=EXTENDED, it can be larger. 因此,原因可能是: - 原始导出环境是12c with EXTENDED, 但导入环境是11g or STANDARD. - 或在导入时数据库设置支持该大尺寸。 **解决方法**: 1. **降低长度**:修改源导出以减小字段大小,使之在导入环境中有效。 2. **更改目标数据库设置**: 如果是Oracle 12c及以上,设置MAX_STRING_SIZE=EXTENDED。但此操作具有破坏性,可能需要重建数据库。 3. **手动创建表**:在导入前手动创建表,使用适当长度。 4. **使用数据泵(expdp/impdp)**:旧IMP可能有问题,改用数据泵工具。 由于用户说“还原数据”,可能是在IMP导入dmp文件。 步骤: - 先检查目标Oracle版本。如果是12c或以上,考虑设置MAX_STRING_SIZE=EXTENDED(但这是永久性变化)。 - 或者,编辑导出文件或导入脚本,调整表定义。 - 在IMP导入前运行创建表语句,并修正问题字段。 在引用[1]中,问题在CREATE TABLE语句,所以预处理是解决之道。 回答结构: - 解释错误原因。 - 逐步解决方案。 - 保持清晰、可靠。 结束时生成相关问题。 引文: - [^1] 是例子。 - [^2] 是官方文档。 在回答中引用它们。 </think> ### 解决Oracle还原数据时出现ORA-00910错误的方案 当您在Oracle中使用`IMP`工具还原数据时遇到ORA-00910错误(“指定的长度对于数据类型而言过长”),这通常是由于数据库对象的定义(如表的字段数据类型长度)超过了当前Oracle版本或设置的允许范围所致。该错误在CREATE TABLE语句执行时触发[^1]。以下是详细的解决步骤和建议。注意:操作前务必备份数据以防止意外损坏。 --- ### 错误原因 错误根源是表中某个字段的数据类型长度定义超出了Oracle的硬性限制: - 对于VARCHAR2或NVARCHAR2类型,最大长度限制取决于Oracle版本和数据库参数设置: - **Oracle 11g及更早版本**:NVARCHAR2的最大长度是2000字符(因为每个字符占用2字节),VARCHAR2是4000字节。如果定义如NVARCHAR2(4000),会直接报ORA-00910[^1][^2]。 - **Oracle 12c及以上版本**:如果参数`MAX_STRING_SIZE=STANDARD`(默认),限制与11g相同;如果设置为`EXTENDED`,则允许NVARCHAR2最大32767字符(但这需要数据库重建)。 - 错误示例:在引用[1]中,`FTEXTVALUE NVARCHAR2(4000)`在11g环境中会导致ORA-00910,因为4000字符超限(实际最大2000字符)。 - 其他原因可能包括字符集设置(多字节编码如UTF8影响实际字节消耗)或导入文件语法错误[^1]。 --- ### 逐步解决方案 针对`IMP`导入时的ORA-00910错误,按以下步骤处理: 1. **验证Oracle版本和参数设置** - 运行以下SQL查询确认数据库版本和参数: ```sql SELECT * FROM v$version; SELECT value FROM v$parameter WHERE name = 'max_string_size'; ``` - **结果分析**: - 如果版本为11g或更早,最大NVARCHAR2长度可能为2000字符。 - 如果版本12c及以上且`MAX_STRING_SIZE=STANDARD`(默认),限制同11g。 - 解方案:记下限制值,用于后续调整。 2. **检查并修正表定义** - 从导出文件或错误消息中提取CREATE TABLE语句(如引用[1]中的`T_CSL_DYNAITEMDATAENTRY`表)。 - **修正过长的字段定义**: - 如果字段定义为`NVARCHAR2(4000)`且目标数据库是11g,将其改为`NVARCHAR2(2000)`。 - 示例:查找问题字段(如`FTEXTVALUE`),调整长度至安全范围(基于步骤1的限制)。 - 使用SQL*Plus提前手动创建修正后的表: ```sql -- 示例:修改字段长度 CREATE TABLE T_CSL_DYNAITEMDATAENTRY ( FID VARCHAR2(44) NOT NULL, FTEXTVALUE NVARCHAR2(2000), -- 从4000下调 ...其他字段... ); ``` - 确认后重新导入数据(跳过表创建): ```bash imp user/password@database FILE=export.dmp IGNORE=y TABLES=T_CSL_DYNAITEMDATAENTRY ``` 3. **升级数据库设置(高级选项)** - **Oracle 12c及以上**:考虑启用`MAX_STRING_SIZE=EXTENDED`以支持更大长度(如NVARCHAR2支持32767字符)。但此操作破坏性极强: - 运行官方脚本: ```sql ALTER SYSTEM SET max_string_size=EXTENDED SCOPE=SPFILE; SHUTDOWN IMMEDIATE; STARTUP UPGRADE; @?/rdbms/admin/utl32k.sql; -- 重建数据字典 SHUTDOWN IMMEDIATE; STARTUP; ``` - **风险警告**:此操作可逆,可能需重建所有对象。仅建议在开发环境或备份后进行。 - **字符集调整**:如果原始导出使用多字节字符集(如UTF8),且目标数据库设置同,可能导致字节数计算错误。统一字符集或减少长度更为安全[^2]。 4. **替代导入工具(推荐)** - **改用Data Pump工具(expdp/impdp)**:Oracle官方推荐的新工具,支持更大长度和更好的兼容性: - 导出数据: ```bash expdp user/password DIRECTORY=dpump_dir DUMPFILE=export.dmp ``` - 导入数据(自动处理兼容问题): ```bash impdp user/password DIRECTORY=dpump_dir DUMPFILE=export.dmp REMAP_SCHEMA=source_schema:target_schema ``` - **使用SQL*Loader**:手动将数据加载到预创建表中。 5. **处理导出文件问题** - 如果导出文件是旧格式(如IMP的dmp文件),可能包含语法错误: - 修复方法:使用`imp`的`INDEXFILE`选项生成SQL脚本,手动修正后执行: ```bash imp user/password INDEXFILE=fix.sql FILE=export.dmp ``` - 编辑`fix.sql`,改正超长字段后,运行SQL脚本创建表。 --- ### 预防措施 - **开发测试**:在源端使用相同Oracle环境测试导入操作。 - **一致性检查**:保证源和目标数据库版本和参数设置一致- **监控长度**:设计表时避免使用极限长度(如NVARCHAR2(4000)),预留安全余量。 通过以上步骤,大多数ORA-00910错误可以解决。如果问题持续,请提供具体表结构和环境细节以便深入分析[^1][^2]。
<think>我们分析SQL报错:ORA-00932: inconsistent datatypes: expected CHAR got NUMBER 这个错误通常发生在尝试对兼容的数据类型进行操作时。在这里,错误消息指出期望CHAR类型却得到了NUMBER类型。 观察SQL表达式,问题可能出现在日期时间字段的算术运算上。在Oracle中,日期相减得到的是天数(数值类型),然后乘以24转换为小时(仍然是数值类型)。但是,如果字段中某些列实际上是字符类型(CHAR或VARCHAR2)而是日期类型,那么就会导致类型一致。 在给定的表达式中,我们有以下操作: (P.BTW_END_TIME - P.BTW_START_TIME) * 24 (P.LAST_END_TIME - P.LAST_START_TIME) * 24 如果P.BTW_END_TIME, P.BTW_START_TIME, P.LAST_END_TIME, P.LAST_START_TIME这些列中有一个或多个是字符类型,而其他是日期类型,或者它们都是字符类型,那么进行减法运算就会报错,因为字符类型能直接相减。 另外,注意GREATEST和LEAST函数要求所有参数是相同的数据类型。因此,如果P.INTIME, T.CLOCK11, P.BTW_START_TIME等这些字段的数据类型一致,也会导致错误。 解决方案: 1. 确认所有涉及日期比较和运算的字段都是日期类型(DATE, TIMESTAMP等),而是字符类型。 2. 如果某些字段是字符类型,但存储的是日期格式的字符串,则需要将它们转换为日期类型后再进行运算。 例如,如果P.BTW_START_TIME是字符类型,那么应该使用TO_DATE函数转换: TO_DATE(P.BTW_START_TIME, '格式字符串') 但是,由于格式字符串需要根据实际存储的格式指定,所以需要知道确切的格式。 另外,在CASE表达式中,我们进行了日期比较(使用GREATEST和LEAST)和日期减法运算,因此所有参与这些操作的字段都必须是日期类型。 因此,我们需要检查: - P.INTIME - T.CLOCK11, T.CLOCK12 - P.BTW_START_TIME, P.BTW_END_TIME - P.LAST_START_TIME, P.LAST_END_TIME - P.OUTTIME 这些字段的数据类型。如果其中存在字符类型,则需要在运算前转换。 修改后的SQL可能如下(假设字符类型的日期格式为'YYYY-MM-DD HH24:MI:SS',如果是,请调整格式): ```sql CASE WHEN GREATEST(TO_DATE(P.INTIME, 'YYYY-MM-DD HH24:MI:SS'), TO_DATE(T.CLOCK11, 'YYYY-MM-DD HH24:MI:SS')) <= TO_DATE(P.BTW_START_TIME, 'YYYY-MM-DD HH24:MI:SS') AND LEAST(TO_DATE(P.OUTTIME, 'YYYY-MM-DD HH24:MI:SS'), TO_DATE(T.CLOCK12, 'YYYY-MM-DD HH24:MI:SS')) >= TO_DATE(P.BTW_END_TIME, 'YYYY-MM-DD HH24:MI:SS') THEN (TO_DATE(P.BTW_END_TIME, 'YYYY-MM-DD HH24:MI:SS') - TO_DATE(P.BTW_START_TIME, 'YYYY-MM-DD HH24:MI:SS')) * 24 ELSE 0 END + CASE WHEN GREATEST(TO_DATE(P.INTIME, 'YYYY-MM-DD HH24:MI:SS'), TO_DATE(T.CLOCK11, 'YYYY-MM-DD HH24:MI:SS')) <= TO_DATE(P.LAST_START_TIME, 'YYYY-MM-DD HH24:MI:SS') AND LEAST(TO_DATE(P.OUTTIME, 'YYYY-MM-DD HH24:MI:SS'), TO_DATE(T.CLOCK12, 'YYYY-MM-DD HH24:MI:SS')) >= TO_DATE(P.LAST_END_TIME, 'YYYY-MM-DD HH24:MI:SS') THEN (TO_DATE(P.LAST_END_TIME, 'YYYY-MM-DD HH24:MI:SS') - TO_DATE(P.LAST_START_TIME, 'YYYY-MM-DD HH24:MI:SS')) * 24 ELSE 0 END AS REST_HRS ``` 但是,请注意: - 如果这些字段已经是日期类型,则需要转换,否则转换会出错。 - 另外,转换函数需要确保字符串的格式与指定的格式完全匹配,否则会转换失败。 因此,最佳实践是先将表结构中的这些字段改为日期类型。如果无法修改表结构,则必须使用TO_DATE进行转换,并确保格式字符串正确。 此外,还要注意:如果字段中有空值,转换可能会失败,需要处理空值情况(例如使用NVL函数)。 另一种可能性:在原始SQL中,可能某些列是日期类型,而另一些是字符类型,导致GREATEST/LEAST函数内部类型一致而报错。因此,统一类型是关键。 总结:错误的原因是日期运算中混用了字符类型和数值(日期)类型,需要将所有参与日期运算的列转换为日期类型。 </think> 根据ORA-00932错误分析,问题核心是**日期字段类型统一**。在Oracle中,日期相减运算要求所有操作数必须是日期类型(DATE/TIMESTAMP),但您的查询中混用了字符型(CHAR/VARCHAR2)和数值型字段。以下是详细解决方案: ### 错误原因及修复方案 1. **类型匹配问题** `P.BTW_END_TIME - P.BTW_START_TIME`这类运算要求两个字段**必须是日期类型**。如果任一字段存储为字符串(如`VARCHAR2`),Oracle无法直接进行日期运算。 2. **解决方案** 使用`TO_DATE()`统一转换字符型字段(假设日期格式为`YYYY-MM-DD HH24:MI:SS`): ```sql CASE WHEN GREATEST(P.INTIME, T.CLOCK11) <= TO_DATE(P.BTW_START_TIME, 'YYYY-MM-DD HH24:MI:SS') AND LEAST(P.OUTTIME, T.CLOCK12) >= TO_DATE(P.BTW_END_TIME, 'YYYY-MM-DD HH24:MI:SS') THEN (TO_DATE(P.BTW_END_TIME, 'YYYY-MM-DD HH24:MI:SS') - TO_DATE(P.BTW_START_TIME, 'YYYY-MM-DD HH24:MI:SS')) * 24 ELSE 0 END + -- 对LAST_TIME字段同样处理 CASE WHEN ... ``` ### 关键检查点 - 📅 **验证字段类型**:执行以下SQL确认字段实际类型: ```sql SELECT DATA_TYPE FROM ALL_TAB_COLUMNS WHERE TABLE_NAME = 'YOUR_TABLE' -- 替换实际表名 AND COLUMN_NAME IN ('BTW_START_TIME','BTW_END_TIME','LAST_START_TIME','LAST_END_TIME'); ``` - ⚠️ **空值处理**:如果字段可能为NULL,添加`NVL()`避免转换失败: ```sql TO_DATE(NVL(P.BTW_START_TIME, '1900-01-01 00:00:00'), 'YYYY-MM-DD HH24:MI:SS') ``` - ⏱️ **时区问题**:若涉及时区,改用`TO_TIMESTAMP_TZ()`替代`TO_DATE` ### 优化建议 1. 永久性修复:将表字段改为`DATE`类型 ```sql ALTER TABLE your_table MODIFY (BTW_START_TIME DATE); ``` 2. 使用CTE预先转换类型,避免重复调用函数: ```sql WITH converted AS ( SELECT TO_DATE(BTW_START_TIME, 'YYYY-MM-DD HH24:MI:SS') AS btw_start, TO_DATE(BTW_END_TIME, 'YYYY-MM-DD HH24:MI:SS') AS btw_end FROM your_table ) SELECT (c.btw_end - c.btw_start)*24 ... ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值