sqlldr时候Field in data file exceeds maximum length

本文介绍使用SQL*Loader导入数据时遇到的字符长度超过255导致的错误问题及解决方法。需要在控制文件中明确指定字符类型长度。

测试部使用sqlldr入库的时候遇到一个奇怪的问题 ,明明字段长度是256,数据文件中的列长度也是256,却报Field in data file exceeds maximum length问题,后来试着将字段长度改成280\300\1300照样导不进去,觉得很奇怪


   查询MOS找到了答案:

fix:

Change controlfile to define column as CHAR ('length') 

SQL*Loader does not have the concept different character datatypes.  Incoming 
character data is assumed to be type char with a default length of 255. Thus, 
if the character string in the source Data File is more than 255 characters you 
will receive this error.   


   原来sqlldr引擎在检验数据文件的时候,遇到字符类型的时候,默认不能超过255,超过了就报错,如果想load超过255的字符,需要在控制文件中指明:

adress char(256),

   


   可以看出sqlldr引擎的数据校验只是基于规则的校验,不会考虑实际表字段,这可能也是基于性能的一个考虑

<think> 嗯,用户想了解Zigbee ASH协议中Data Field内容的定义。这个问题很专业,需要准确解析协议细节。 ASH协议是TI专为Zigbee设计的传输层协议,它的Data Field结构需要仔细说明。首先想到数据帧最外层是帧头,包含两个字节的控制信息。其中低10位是数据长度,这是关键字段,因为用户特别关注Data Field定义。 接下来要解释Data Field的组成结构。它包含三个主要部分:传输层头部、NWK帧和载荷。传输层头部有帧类型和分片控制信息,这部分需要具体说明各种帧类型的值范围。NWK帧就是标准的Zigbee网络层数据包,而载荷才是最终的应用数据。 用户可能混淆了ASH和Zigbee协议栈的关系,需要特别指出ASH是底层传输协议,真正的Zigbee数据封装在NWK帧里。这样用户就能理解Data Field在整个协议栈中的位置了。 考虑到用户的技术背景,补充说明校验机制也很重要。ASH使用CRC-16校验整个数据帧,这是确保传输可靠性的关键机制。最后用具体格式示例展示会更直观,比如最小数据帧的字节分布。 用户之前查询过协议相关内容,这次问题更聚焦特定字段定义,说明ta在进行底层开发或调试。回答时需要兼顾技术准确性和可读性,避免过于晦涩的术语堆砌。 </think> Zigbee ASH(Advanced Serial Host)协议是德州仪器(TI)为其Zigbee SoC(如CC253x)设计的专有串行传输协议,用于在主机处理器(如MCU)和Zigbee网络协处理器(NCP)之间传输数据帧。**ASH协议Data Field的内容定义如下:** **Data Field结构 (在ASH帧中):** ``` | ASH Frame Header (2 Bytes) | Data Field (Variable Length) | FCS (2 Bytes) | ASH Frame Footer (1 Byte) | ``` 1. **ASH Frame Header (2 Bytes):** * **低10位 (Bits 0-9):** **数据长度 (Data Length)**。指示`Data Field`包含的**字节数**。这是定义`Data Field`边界的关键字段[^1]。 * **高6位 (Bits 10-15):** **控制位 (Control Bits)**。包含帧类型(如数据帧、ACK帧、NAK帧等)、重传标志、流控标志等信息。 2. **Data Field (变长 - 由Header中的长度域决定):** * **这才是ASH协议承载的`有效载荷`**,其内部结构由其上层的协议(主要是Zigbee协议栈)定义。 * **Data Field内容 = 传输层头部 + NWK帧** * **传输层头部 (Transport Header, 1 Byte):** * 包含帧类型和分片控制信息。 * **Bit 7:** `Frame Type` - `0` 表示数据帧 (Data Frame), `1` 表示命令帧 (Command Frame)。Zigbee应用数据通常封装在数据帧中。 * **Bits 5-6:** `Subsystem` - 指示该帧属于哪个子系统(如`0x01`表示`SYS`, `0x02`表示`MAC`, `0x03`表示`NWK`, `0x04`表示`AF`等)。Zigbee数据包通常在`NWK`子系统。 * **Bits 0-4:** `Command ID` - 子系统内的具体命令标识符。对于来自应用的数据,通常是`Data Request`或`Data Confirm`等命令的标识符。 * **NWK帧 (Network Frame):** * 这是一个完整的、符合Zigbee NWK层规范的数据包。 * **NWK Header:** 包含NWK层控制信息、源/目的地址、半径、序列号等。 * **APS Payload:** 包含Zigbee应用层(APS)的帧头和安全头(如果启用)。 * **Application Payload:** **最终的用户应用程序数据**,即您通过Zigbee网络发送的实际信息内容(如传感器读数、控制命令等)[^2]。 3. **Frame Check Sequence (FCS) (2 Bytes):** * 对整个ASH帧(包括Header和Data Field)进行**CRC-16校验**,用于检测传输错误。 4. **ASH Frame Footer (1 Byte):** * 固定值`0x7E`,作为帧结束分隔符。 **总结关键点:** * ASH协议`Data Field`的**长度**由ASH帧头的低10位明确指定。 * `Data Field`内部包含一个**传输层头部**和一个完整的**Zigbee NWK层帧**。 * **传输层头部**标识了该帧所属的子系统(如NWK)和具体的命令类型。 * **Zigbee NWK帧**内部封装了APS层帧,最终在**APS Payload**中携带了**用户应用程序的实际数据**。 * ASH协议本身不定义应用数据的格式,它只是可靠传输Zigbee协议栈生成的NWK帧的载体。应用数据的结构由Zigbee应用层(APS)和具体的Profile/Cluster定义。 **简单示例 (一个携带Zigbee应用数据的最小ASH数据帧结构):** ``` | 0x00 0x07 | ... | ... | 0xXX | ... | ... | ... | ... | ... | ... | ... | ... | ... | 0xYY 0xZZ | 0x7E | |-- ASH Header (2B) --|----------------------- Data Field (7 Bytes) -----------------------|-- FCS (2B) --|Footer| ``` * ASH Header `0x00 0x07`: 低10位`0x0007` = 7, 表示Data Field长度为7字节。 * Data Field (7 Bytes): * Transport Header (1B): 例如 `0x25` (Bit7=0数据帧, Bits5-6=01 NWK子系统, Bits0-4=0x05 可能是Data Request命令ID)。 * NWK Frame (6B): 一个简化的NWK帧(包含NWK头、简化的APS头和少量应用数据)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值