数据类型 text 和 nvarchar 在等于运算符中不兼容

问题描述

这是我的代码

ProductController.cs

public ActionResult Details(string id)
{
    product productx = productDB.products.Single(pr => pr.Product1 == id);
    return View(productx);


}

Details.aspx

    <td>
        <%-- : Html.ActionLink("Edit", "Edit", new { id=item.Id }) % --> 
        <%: Html.ActionLink("Details", "Details", new { id = item.Product1 })%>
    </td>

这是我用来从 sql 数据库中列出一些产品的方法，每个产品都有一个指向详细信息页面的链接以显示有关它的更多信息

this is what im using to list some products from a sql database, each product have a link to a Details page to show more informations about it

我试图只将产品标签放在该链接中，让它显示类似www.mysite.comproductsattery(不是ID)

what Im trying is to only put the product label in that link to let it show something like www.mysite.comproductsattery (not the id)

我认为这应该可行，但它会抛出一个数据类型 text 和 nvarchar 在等于运算符中不兼容. 错误和(pr => pr.Product1.Equals(id)); 都不起作用

I've imagined this should work, but it throw an The data types text and nvarchar are incompatible in the equal to operator. error and neither (pr => pr.Product1.Equals(id)); works

错误很明显，我问我应该怎么做才能让它以这种方式工作?

the error is clear and Im asking how should I do to make it work this way ?

谢谢

推荐答案

TEXT 列被视为大对象数据，因此不可索引/可搜索.它们也已弃用.所以，实际上，问题出在您的数据库中，而不是您的应用程序中.

TEXT columns in SQL Server are considered Large Object data and therefore aren't indexable/searchable. They're also deprecated. So, actually, the problem is in your database, not in your application.

如果将列类型更改为 varchar(max)，则可以存储相同数量的字符数据，但应该不会出现此问题.然后，将您的 Linq 更新为 SQL 实体，您将不再遇到此特定错误.

If you change the column type to a varchar(max), you can store the same amount of character data but shouldn't have this problem. Then, update your Linq to SQL entity, and you'll no longer get this particular error.

话虽如此……名为ID的列不应该是TEXT 或 varchar(max)，它应该是一个自动递增的整数 ID 或 GUID (uniqueidentifier)，因此您可能需要重新访问您的数据库设计.但假设您有充分的理由将 ID 设为任意大小的字符串值，上述更改将允许您对列进行过滤.

Having said that... a column named ID shouldn't be TEXT or varchar(max), it should be an auto-increment integer ID or a GUID (uniqueidentifier), so you might want to revisit your DB design. But assuming you have good reasons for IDs to be string values of arbitrary size, the above change will allow you to filter on the column.