SSIS OLE DB数据流源:输出可能具有不同长度的列
我创建了一个 SSIS 包,这样我就可以按计划的时间间隔从旧版 FoxPro 数据库导入数据。为多个客户安装了 FoxPro 数据库的副本。总的来说,这个包运行得很好并且完成了我需要的一切。
然而,我遇到了一种恼人的情况,其中至少一个客户(也许更多)有一个修改过的 FP 数据库,他们增加了一个表中一列的长度。当我在这样的客户上运行该包时,由于截断而失败。
我想我可以给自己一些回旋余地,将长度从 3 更改为 10。这样,长度为 10 的突变体以及其他使用 3 的人都会被容纳。但是,当列长度不满足时,SSIS 会抱怨。 t 匹配,期间。
我想我有几个选择:
- 在任务中,将“ValidateExternalMetadata”设置为 false。但是,我不确定这是最负责任的选择……是吗?
- 让我们的实施团队将所有客户的长度更改为 10。这可能是一个问题,但至少这是他们的问题。
- 创建适用于具有不同列长度的解决方案的任务副本。在某些时候,实现可能会使用错误的包,每个人都会问我为什么不直接给他们一个无法处理所有场景的包,并将其归咎于我。
- 使用其他一些你可能可以告诉我的方法。
I created an SSIS package so I can import data from a legacy FoxPro database at scheduled intervals. A copy of the FoxPro databaseis installed for several customers. Overall, the package is working very well and accomplishing all that I need.
However, I have one annoying situation where at least one customer (maybe more) has a modified FP database, where they increased the length of one column in one table. When I run the package on such a customer, it fails because of truncation.
I thought I could just give myself some wiggle room and change the length from 3 to 10. That way the mutants with a length of 10 would be accommodated, as well as everyone else using 3. However, SSIS complains when the column lengths don't match, period.
I suppose I have a few options:
- On the task, set 'ValidateExternalMetadata' to false. However, I'm not sure that is the most responsible option... or is it?
- Get our implementation team to change the length to 10 for all customers. This could be a problem, but at least it would be their problem.
- Create a copy of the task that works for solutions with the different column length. Implementation will likely use the wrong package at some point, and everyone will ask me why I didn't just give them a single package that couldn't handle all scenarios and blame this on me.
- Use some other approach you might be able to fill me in on.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您使用的是 Visual FoxPro OleDB,并且您关心列宽,则可以在调用期间使用 PADR() 显式强制它们。我不知道这会影响多少表/查询,但可以保证您获得预期的字符列长度。如果处理数字、小数、日期/时间、逻辑(布尔),应该不是问题...无论如何,您可以这样做作为您选择获取数据
这将强制基于字符(隐含示例)字段“CharFld3” 、“CharFld4”、“CharFld6”分别为 20、5 和 35 的力宽度,无论底层结构长度如何。现在,如果有人更新的结构比您拥有的结构更长,它将被截断到适当的长度,但不会崩溃。此外,如果它们的列长度较短,它将被填充到您通过 PADR() 函数指定的完整大小(填充右侧)。
If you are using the Visual FoxPro OleDB, and you are concerned about the columns widths, you can explicitly force them by using PADR() during your call. I don't know how many tables / queries this impacts but would guarantee you get your expected character column lengths. If dealing with numeric, decimal, date/time, logical (boolean), should not be an issue... Anyhow, you could do this as your select to get the data
This will force character based (implied sample) fields "CharFld3", "CharFld4", "CharFld6" to a force width of 20, 5 and 35 respectively regardless of the underlying structure length. Now, if someone updates the structure LONGER than what you have it will be truncated down to proper length, but won't crash. Additionally, if they have a shorter column length, it will be padded out to the full size you specify via the PADR() function (pad right).
我在 FoxPro 方面很弱,但是...
您可以创建一个满足 SSIS 期望的临时表。创建一个任务,使用 FoxPro 指令将数据从问题表复制到临时表。更改数据流以使用临时表。
您可以将初步步骤(创建临时表并传输到临时表)创建为 SSIS 任务,以便由 SSIS 包管理流程控制。
I'm weak on the FoxPro side, but...
You could create a temporary table that meets the SSIS expectations. Create a task that would use FoxPro instructions to copy the data from the problem table to the temporary table. Alter your data flow to work with the temp table.
You can create the preliminary steps (create temp table and transfer to temp table) as SSIS tasks so that flow control is managed by your SSIS package.