表SQL每行中的空白

Question

你好，我有一张有行的桌子

我正在做一个简单的

select from table where column ='string'

它没有给我任何结果，但是当我使用时：

select from table where column ='%string%'

它为我提供了表格中存在的行，

然后我做了一个select * from table，并注意到在我的行之前有一个空格：

Image of my SQL result

如果仔细观察，第二行的开头会有一个空格，只有第一行没有空格。

所以我以为这是一个简单的空白，但是当我尝试使用它时：

SELECT LTRIM(RTRIM(MATERIAL)) FROM table

什么都没发生。

然后我尝试复制

的结果

select * from table

到Excel并注意到：

Excel paste from SQL

我的第二行在“材料”列的开头被分成了两行，所以我想这是一个空白，有点像跳线。

我以前从未遇到过这个问题，也从未见过这个问题。

Answer 1

Larnu评论了如何从数据中删除所有换行符。以下是一些其他可行的方法，根据您想要的效果略有不同：

--trim everything that is not a number or letter off the left hand side only
UPDATE table SET material = SUBSTRING(material, PATINDEX(material, '[0-9a-z]', 99999)

--convert all linebreaks to spaces and trim off the left and right spaces
UPDATE table SET material = RTRIM(LTRIM(REPLACE(material, CHAR(10), ' ')))

Larnu的SQL没错，它只会删除任何位置的每个换行符，这可能会导致超出预期范围的格式化中断。我很想用空格替换所有的换行符，因为用换行符分隔的两个单词将保持空格分隔，而不是如果删除空格则变成一个单词

some
word

-> some word (if you replace linebreak with space)
-> someword (if you replace linebreak with nothing)

如果只想从字段的左侧删除换行符，则patindex方法将在该字段中搜索字母首次出现的numbe rof，然后返回索引，然后子字符串将从该索引中删除所有内容长度为99999（如果您的字段较长，则使用更大的数字）。这样的效果是仅删除字段开头的换行符

关于它的发生方式，无论谁插入数据或数据导入程序，在切割数据时都会犯一些错误。也许这是Windows样式的文本文件，其行尾是CR LF（ascci 13，后跟10），并且执行导入的程序决定仅基于13来分割文件，而将10留下来成为“一部分”的“材料领域”：

this,is,my,data1<13><10>this,is,my,data2<13><10>

//now lets cut it up into 2 records, based on using <13> only to denote the end of line:

record 1= this,is,my,data1
record 2= <10>this,is,my,data2

该程序只看到字节流，这是我们人类解释的“行”。如果程序将13视为分隔符，则所有10都将作为所插入数据的一部分被抛在后面。文件中的第一条记录之前不会有13/10（crlf），因为它是第一行，因此您的某一行（具有ascii（49）的行）不会遇到此问题

您可以在插入时使用触发器“治愈”不良数据：

CREATE TRIGGER prevent_bad_data
ON yourtable  
INSTEAD OF INSERT
AS
  BEGIN
      INSERT INTO yourtable(somecolumn,othercolumn,material)
      SELECT foo,
             bar,
             LTRIM(REPLACE(material, CHAR(10), ' '))
      FROM   Inserted
  END  

或者您可以对数据库进行编程以拒绝不良行并修复插入不良数据的工具：

ALTER TABLE yourtable
ADD CONSTRAINT prevent_bad_material 
CHECK material LIKE '[0-9a-z]%';  --check it starts with a number or letter

编辑：尽管看到了有关屏幕截图的更新问题，但材料栏确实应该是数字，而不是varchar类型，否则不会发生