将 csv 导入记录集时出现奇怪的问题
我正在尝试将 csv 导入到记录集中。我一直在使用 stackoverflow 用户
不过最近开始出现奇怪的错误。在所有情况下,文件都会被打开和读取,而不会引发任何错误。
症状(经过大量测试!)
有时会在给定(大)字段空白的情况下导入某些行(下面的粗体文本未导入)
£0.00,0.00,£0.00,£0.00,,,,,,,"伯明翰- OCW1","N221A-BIR","开关",0,,,04/02/2011 14:16:00,0," 工作由 James Helanor 更新于 04/02/2011 05:50。
工作由 Scott Murgatroyd 更新于 04/02/2011 08:02。
工作由 Scott Murgatroyd 于 04/02/2011 10:05 更新。
工作由 Sean Hatherley 更新于 04/02/2011 11:10。
工作由 Dawn Marie 更新于 04/02/2011 11:55。
工作由 Sean Hatherley 更新于 04/02/2011 12:00。
工作由 Sean Hatherley 更新于 04/02/2011 13:13。
工作由 James Helanor 于 05/02/2011 06:03 发送,有风险:,
工作由 Sean Hatherley 于 08/02/2011 14:57 更新。
工作由 Sean Hatherley 更新于 08/02/2011 14:59。
工作更新于 09/02/2011 08:26,作者:O2 Engineer 2。
工作更新:工作,更新于 10/02/2011 08:47,作者:Sean Hatherley。
工作由 Sean Hatherley 更新于 15/02/2011 10:48。
工作由 Sean Hatherley 更新于 18/02/2011 10:25。
由 Sean Hatherley 于 24/02/2011 11:27 完成
由 O2 Engineer 2 于 11/03/2011 15:56 恢复(反应式尚未完成) ---- 11/03/2011 15:53 作者:O2 工程师 2:** 案例保持开放** 工作由 O2 工程师 2 于 21/03/2011 07:29 更新。 ",,,,"JAMES","P1 非工作时间紧急情况",£0.00,0.00,£0.00,0.00,"已发布",04/02/2011 05:26:40,0.00,,,0,,04 /02/2011 05:26:00,"C63024","Adams 警报 - 9 楼 EMX AHU 4 提示","OOH 物业","优先级 1",1,-1,,,,"服务台",04/ 02/2011 05:26:00,"否","F80-03-03","01753 564 222",04/02/2011 11:30:00,04/02/2011 06:56:00,, ,"进行中","BTW-OOH","BT 批发 - S","---- 04/02/2011 05:50 作者:James Helanor:致电 BT 以告知故障 - 给出 TH32330 的参考- 发送手动文本以告知故障,但尚未到达预计时间 ---- 04/02/2011 08:02 作者:Scott Murgatroyd:作业已传递给 BT eng,正在更新发送的文本 ---- 04/02/2011 10:05 作者:Scott Murgatroyd:BT 工程师出席,更新发送的文本 ---- 04/02/2011 11:10 作者:Sean Hatherley:据英国电信工程师介绍,他将在 20 分钟内赶到现场。 ---- 04/02/2011 11:53 作者:Dawn Marie:来自 Babu Patel 07711640502 的更新 BT 工程师在现场,设备因低压跳闸,Babu 正在尝试查找制冷剂泄漏,但这可能需要几天时间才能找到。 ---- 04/02/2011 11:59 作者:Sean Hatherley:Rang Adam Elvidge,他建议将其保留为 P1,每天追逐,而不是每小时 4 次。 ---- 04/02/2011 13:12 作者:Sean Hatherley:短信已发送 ---- 08/02/2011 14:57 作者:Sean Hatherley:BT 将于 2011 年 9 月 2 日重新参加以纠正低压故障。给 Adam Elvidge 打电话,看看是否可以降级。 ---- 09/02/2011 08:25 作者:O2 工程师 2:Adam Elvidge- 保留 P1 身份的情况 ---- 10/02/2011 08:44 作者:Sean Hatherley:在 BT 的追踪下,他们还没有进一步的更新,但正在将其传递给他们的工程师来回电。 ---- 15/02/2011 10:47 作者:Sean Hatherley: 追着BT,他们没有进一步的更新。 ---- 18/02/2011 10:24 作者:Sean Hatherley:打电话给 BT,去了溢出办公室,他们会追捕工程师并回电更新,因为更新在他们的系统上仍然打开。 ---- 24/02/2011 11:27 作者:Sean Hatherley:亚当斯的警报现已清除,工作结束 ---- 11/03/2011 15:54 作者:O2 工程师 2:煤气泄漏尚未修复,正在等待 BT 区域经理 John Greenfield 的更新。 ---- 21/03/2011 07:28 作者:O2 工程师 2:案件悬而未决,等待 BT 就当前状态作出答复。案例保持开放",,,,,
造成这种情况的原因似乎至少是 CSV 中的另一行:
£0.00,0.00,£0.00,£0.00,,,,,"AF PO RAISED" ,"采购订单已提高","克罗伊登 - OCW1","N221A-CRO","切换",,,,08/03/2011 11:32:00,0," 工作由 Sarah Northveth 于 08/02/2011 11:32 发送,风险:,
工作由 Ann Farish 于 09/02/2011 07:56 更新。
作业于 09/02/2011 07:57 发送,作者:Ann Farish,有风险:,
作业更新于 09/02/2011 09:03,作者:Priya Mistry。
工作由 Sean Hatherley 更新于 15/03/2011 15:21。
工作由 Sean Hatherley 于 15/03/2011 15:21 发送,有风险:,
工作由 Sean Hatherley 于 15/03/2011 15:28 更新。
作业由 Sean Hatherley 于 15/03/2011 15:29 发送,存在风险:, ",,,"02/12980","SARAHN","P4 CWP 工程师开展项目工程",£0.00,0.00,£0.00,0.00,"已发布",08/02/2011 11:32:06, 0.00,,,0,,08/02/2011 11:32:00,"C63448","更换 UPS 系统上的风扇","ISS-Engineer","优先级 4",4,-1,,,,"希尔顿古姆斯",08/02/2011 11:32:00,"是","工程师","07702368336",,08/03/2011 11:32:00,,,"进行中","CWP-ENG -HGUMBS","Hilton Gumbs - D","_---- 09/02/2011 07:56 作者:Ann Farish:PO 已要求艾默生更换 Hilton Gumbs 的风扇 ---- 09/02/2011 09:03 作者 Priya Mistry:po 批准并发出 ---- 15/03/2011 15:21 作者:Sean Hatherley:已通过电子邮件向希尔顿发送更新信息 ---- 15/03/2011 15:28 作者:Sean Hatherley:希尔顿更新:UPS 风扇将于 2011 年 7 月 4 日更换
_",£0.00,"ENG-CRO-EAL","HILTON GUMBS", 30/12/1899 00:00:00,
如果我在要导入的文件中包含这一行,上面的粗体文本就会消失,如果我离开这一行,它会导入正常
,结果似乎取决于 。上一行的位置以及包含多少其他行,
如果我只导入这两行,一切正常,如果我导入两行以及许多其他行,则只要导入。第二行位于文本文件的后半部分
更奇怪的是,如果我将斜体标记的字段值减少到不到 244 个字符,那么一切都会正常工作吗
?有什么想法吗?非常欢迎
。
I'm trying to import a csv into a recordset. I've been using code kindly provided by a stackoverflow user here and it worked well for a long time.
Have started to get a bizarre error recently though. In all cases the file is opened and read without throwing any errors.
SYMPTOMS (AFTER LOTS OF TESTING!)
Certain rows are SOMETIMES imported with a given (large) field blank (text in bold below isn't imported)
£0.00,0.00,£0.00,£0.00,,,,,,,"Birmingham - OCW1","N221A-BIR","Switch",0,,,04/02/2011 14:16:00,0,"
Job Updated On 04/02/2011 05:50 by James Helanor.
Job Updated On 04/02/2011 08:02 by Scott Murgatroyd.
Job Updated On 04/02/2011 10:05 by Scott Murgatroyd.
Job Updated On 04/02/2011 11:10 by Sean Hatherley.
Job Updated On 04/02/2011 11:55 by Dawn Marie.
Job Updated On 04/02/2011 12:00 by Sean Hatherley.
Job Updated On 04/02/2011 13:13 by Sean Hatherley.
Job Despatched On 05/02/2011 06:03 by James Helanor with Risks : ,
Job Updated On 08/02/2011 14:57 by Sean Hatherley.
Job Updated On 08/02/2011 14:59 by Sean Hatherley.
Job Updated On 09/02/2011 08:26 by O2 Engineer 2.
Job Updated On 10/02/2011 08:47 by Sean Hatherley.
Job Updated On 15/02/2011 10:48 by Sean Hatherley.
Job Updated On 18/02/2011 10:25 by Sean Hatherley.
Completed on 24/02/2011 11:27 by Sean Hatherley
Reinstated (Reactive hasn't been completed) on 11/03/2011 15:56 by O2 Engineer 2
---- 11/03/2011 15:53 By O2 Engineer 2:** Case to remain open**
Job Updated On 21/03/2011 07:29 by O2 Engineer 2.
",,,,"JAMES","P1 Out of Hours Emergency",£0.00,0.00,£0.00,0.00,"Issued",04/02/2011 05:26:40,0.00,,,0,,04/02/2011 05:26:00,"C63024","Adams alarm - 9th floor EMX AHU 4 Prompt","OOH Property","Priority 1",1,-1,,,,"Helpdesk",04/02/2011 05:26:00,"no","F80-03-03","01753 564 222",04/02/2011 11:30:00,04/02/2011 06:56:00,,,"In Progress","BTW-OOH","BT Wholesale - S","---- 04/02/2011 05:50 By James Helanor: Called BT to advise of fault - given ref of TH32330 - manual text sent to advise of fault although no eta yet
---- 04/02/2011 08:02 By Scott Murgatroyd: Job passed through to BT eng, updating text sent
---- 04/02/2011 10:05 By Scott Murgatroyd: BT Engineer to attend, updating text sent
---- 04/02/2011 11:10 By Sean Hatherley: As per BT engineer, he will be onsite in 20 minutes.
---- 04/02/2011 11:53 By Dawn Marie: update from Babu Patel 07711640502 BT engineer is on site the unit has tripped on low pressure, Babu is trying to find refrigerant leak but this may take a few days to find.
---- 04/02/2011 11:59 By Sean Hatherley: Rang Adam Elvidge, he advised to leave this as a P1 and to chase daily, not 4 hourly.
---- 04/02/2011 13:12 By Sean Hatherley: Text sent
---- 08/02/2011 14:57 By Sean Hatherley: BT are reattending 09/02/11 to rectify low pressure fault. Rang Adam Elvidge to see if it can be downgraded.
---- 09/02/2011 08:25 By O2 Engineer 2:Adam Elvidge- Case to remain as a P1
---- 10/02/2011 08:44 By Sean Hatherley: Chased with BT, they have no further updates yet but are passing it onto their engineer to ring back.
---- 15/02/2011 10:47 By Sean Hatherley: Chased with BT, they have no further updates.
---- 18/02/2011 10:24 By Sean Hatherley: Rang BT, went to overflow office and they will chase the engineer and ring back with an update as it is still open on their system.
---- 24/02/2011 11:27 By Sean Hatherley: Alarm now cleared on Adams, job closed
---- 11/03/2011 15:54 By O2 Engineer 2: Gas leak hann't been repaired, awaiting an update from the BT area manager John Greenfield.
---- 21/03/2011 07:28 By O2 Engineer 2: Case to be left open, awaiting reply from BT on current status. Case to remain open",,,,,
The cause for this seems to be at least one other row in the CSV:
£0.00,0.00,£0.00,£0.00,,,,,"AF PO RAISED","Purchase order raised","Croydon - OCW1","N221A-CRO","Switch",,,,08/03/2011 11:32:00,0,"
Job Despatched On 08/02/2011 11:32 by Sarah Northveth with Risks : ,
Job Updated On 09/02/2011 07:56 by Ann Farish.
Job Despatched On 09/02/2011 07:57 by Ann Farish with Risks : ,
Job Updated On 09/02/2011 09:03 by Priya Mistry.
Job Updated On 15/03/2011 15:21 by Sean Hatherley.
Job Despatched On 15/03/2011 15:21 by Sean Hatherley with Risks : ,
Job Updated On 15/03/2011 15:28 by Sean Hatherley.
Job Despatched On 15/03/2011 15:29 by Sean Hatherley with Risks : ,
",,,"02/12980","SARAHN","P4 CWP Engineer to carry out Project Works",£0.00,0.00,£0.00,0.00,"Issued",08/02/2011 11:32:06,0.00,,,0,,08/02/2011 11:32:00,"C63448","replace fans on UPS System","ISS-Engineer","Priority 4",4,-1,,,,"Hilton Gumbs",08/02/2011 11:32:00,"Yes","Engineer","07702368336",,08/03/2011 11:32:00,,,"In Progress","CWP-ENG-HGUMBS","Hilton Gumbs - D","_---- 09/02/2011 07:56 By Ann Farish: PO Has been requested for emerson to replace fan by Hilton gumbs
---- 09/02/2011 09:03 By Priya Mistry: po approved and sent out
---- 15/03/2011 15:21 By Sean Hatherley: Emailed Hilton for update
---- 15/03/2011 15:28 By Sean Hatherley: Hilton update: UPS fans due to be replaced on 07/04/2011
_",£0.00,"ENG-CRO-EAL","HILTON GUMBS",30/12/1899 00:00:00,
If I include this row in the file to be imported the text in bold above disappears, If I leave this row out it imports fine.
Here's the weird bit, the outcome seems to depend on the position of the above row and how many other rows are included.
If I import just these two rows everything works fine, If I import both rows with lots of others they import as long as the second row is in the second half of the text file
Even weirder, if I reduce the field value marked in italic to just under 244 characters everything works.
Is this something to do with the recordset making assumptions about what type of data it's handling? Any thoughts very welcome.
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
修好了!
据我了解,系统会对 csv 的数据类型做出有根据的猜测,但在我的例子中,它是错误的。
结果我需要一个 schema.ini 文件(与 csv 位于同一文件夹中)来指定每列的数据类型,如下所示:
[file.txt]
格式=CSVDelimited
字符集=ANSI
ColNameHeader=True
Col1=ActLabCost 文本
Col2=ActLabTime 文本
Col3=ActMatCost 文本
...
我将问题列的列类型设置为 LongChar,一切似乎都正常。
Fixed it!
As I understand it, the system will make an educated guess at the data types of the csv and in my case was getting it wrong.
Turns out I needed a schema.ini file (in the same folder as the csv) to specify the data type of each column along the lines of:
[file.txt]
Format=CSVDelimited
CharacterSet=ANSI
ColNameHeader=True
Col1=ActLabCost text
Col2=ActLabTime text
Col3=ActMatCost text
...
I set the column type of the problem column to LongChar and all seems to be working.