gpt4 book ai didi

c# - Oracle CHAR 数据类型不适用于 Entity Framework

转载 作者:太空狗 更新时间:2023-10-30 01:34:40 24 4
gpt4 key购买 nike

我在使用针对 CHAR 列的 WHERE 子句从 Oracle 数据库返回数据时遇到问题。

我已提供以下步骤,应该可以重现问题:

数据库设置

运行以下 SQL 来创建数据库表并插入模拟数据:

创建表订单(ORDER_NUMBER CHAR(10 BYTE));
插入订单值 ('123456');
SELECT REPLACE(ORDER_NUMBER, ' ', '#') as ORDER_NUMBER 来自 ORDERS

订单号
123456####

如您所见,存储在表中的值用空格填充到 10 个字符(替换为“#”以使其明显)。

Entity Framework 设置

public class Order
{
public string OrderNumber { get; set; }
}

public class OrderMap : EntityTypeConfiguration<Order>
{
public OrderMap()
{
// Primary Key
HasKey(t => t.OrderNumber);

Property(t => t.OrderNumber)
.HasColumnName("ORDER_NUMBER")
.IsRequired()
.IsFixedLength()
.HasMaxLength(10)
.HasColumnType("CHAR")
.IsUnicode(false);
}
}

public class OrdersContext()
{
static OrdersContext()
{
Database.SetInitializer<OrderContext>(null);
}

public DbSet<Order> Orders { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Configurations.Add(new OrderMap());
}
}

问题

class Program
{
static void Main(string[] args)
{
using (var context = new OrdersContext())
{
var order1 = context.Orders
.FirstOrDefault(o => o.OrderNumber == "123456");

// This works, the record is found in the database and I did not have to pad the filter sting to 10 characters
Debug.WriteLine("OrderNumber:" + order1.WorksOrder);

var orderFilter = "123456";
var order2 = context.Orders
.FirstOrDefault(o => o.WorksOrder == orderFilter);

// This fails. Using a variable to specify the filter does not work. No record is found.
Debug.WriteLine("OrderNumber:" + order2.WorksOrder);
}
}
}

所以,问题是当我想使用变量 (orderFilter) 时,语句没有返回记录。我可以按如下方式填充 orderFilter 来完成这项工作,但我认为我不必这样做:

var orderFilter = "123456".PadRight(10);
var order2 = context.Orders.FirstOrDefault(o => o.WorksOrder == orderFilter);

// This now works
Debug.WriteLine("OrderNumber:" + order2.WorksOrder);

使用绑定(bind)变量时生成的 SQL 似乎没有在绑定(bind)变量上设置正确的数据类型。如果我启用跟踪,我们会看到以下 SQL:

Opened connection at 22/04/2015 12:15:12 +01:00

SELECT "Extent1"."ORDER_NUMBER" AS "ORDER_NUMBER", FROM "ORDERS" "Extent1" WHERE ("Extent1"."ORDER_NUMBER" = :p__linq__0) AND (ROWNUM <= (1) )

-- p__linq__0: '123456 ' (Type = Object)

-- Executing at 22/04/2015 12:15:12 +01:00 -- Completed in 13 ms with result: OracleDataReader

我也尝试过使用 DbFunctions.AsNonUnicode(orderFilter) 但这似乎没有什么效果。

谁能解释一下这是怎么回事?如何在不填充过滤器或修剪列数据的情况下过滤 CHAR 数据类型?

注意
我无法更改数据库中列的数据类型。

这个问题记录在几个地方,但没有明确的答案:

所有东西的版本号:

  • Entity Framework 6.1.3
  • .Net Framework 4.5.1
  • Oracle.ManagedDataAccess 4.121.2.0 ODAC 12c 第 3 版
  • Oracle.ManagedDataAccess.EntityFramework 6.121.2.0
  • Oracle 数据库是 11.2.0.3.0

最佳答案

我可以解释发生了什么。解决方案是更改 CHAR 列(我注意到你说你不能),否则在与它进行比较时要注意细微之处。

Tom Kyte 在其精湛著作“Expert Oracle Database Architecture”中关于 CHAR 数据类型的部分是此答案的来源。以下内容基于第 2 版第 499 - 502 页。

简答

字 rune 字得到提升,而可变长度绑定(bind)变量则没有。

解释

(以下所有内容均使用 SQLPlus 针对 12.1.0.2 数据库运行(但没有显示是 12c 独有的)

创建并填充包含 CHAR 和 VARCHAR2 列的表:

CREATE TABLE ORDERS (ORDER_NUMBER_CHAR       CHAR(10 BYTE),
ORDER_NUMBER_VARCHAR2 VARCHAR2(10 BYTE));

INSERT INTO ORDERS(ORDER_NUMBER_CHAR,
ORDER_NUMBER_VARCHAR2)
VALUES ('123456',
'123456');

在 WHERE 子句中使用 VARCHAR2 列的第一个查询中,它按预期工作并返回一行。

SELECT *
FROM orders
WHERE order_number_varchar2 = '123456';

在下一个查询中,WHERE 子句使用 CHAR 列。此查询返回一行,这意味着隐式转换已发生,由此 CHAR(6) 文字被提升为 CHAR(10)

SELECT *
FROM orders
WHERE order_number_char = '123456';

隐式提升一定发生了,因为字符串是不同的此查询显示的长度不返回任何行

SELECT *
FROM orders
WHERE order_number_char = order_number_varchar2;

下一个示例显示 VARCHAR2 绑定(bind)变量未以与字 rune 字相同的方式提升,因此此查询不返回任何行

variable vc2 VARCHAR2(10 BYTE);
exec :vc2 := '123456';

SELECT *
FROM orders
WHERE order_number_char = :vc2;

如果使用了正确的 CHAR 绑定(bind)变量,则会找到记录,最终查询会按预期返回行。

variable the_char CHAR(10 BYTE);
exec :the_char := '123456';

SELECT *
FROM orders
WHERE order_number_char = :the_char;

您还应注意,如果 CHAR 列的大小发生变化,应用程序将受到影响,即如果它增加到 20,则需要相应地更改 PadRight 方法。

最后,我认为也值得完整引用 Tom 对 CHAR 数据类型的总结。

It is for these reasons—the fixed-width storage, which tends to make the tables and related indexes much larger than normal, coupled with the bind variable issue—that I avoid the CHAR type in all circumstances. I cannot even make an argument for it in the case of the one-character field, because in that case it is really of no material difference. The VARCHAR2(1) and CHAR(1) are identical in all aspects. There is no compelling reason to use the CHAR type in that case, and to avoid any confusion, I “just say no,” even for the CHAR(1) field.

关于c# - Oracle CHAR 数据类型不适用于 Entity Framework ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29796389/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com