SSIS 输入变量名称以“Specified”结尾- 为什么?

发布于 2024-11-26 19:26:11 字数 1227 浏览 0 评论 0原文

我正在尝试使用 SSIS 的一些 WCF 服务。我在开发机器上运行得很好。然而,当另一个开发人员尝试这样做时,他们遇到了问题。

如果其他开发人员复制我的 .DTSX 文件,那么它就可以工作。但是,如果他们自己创建它,则它无法连接(从 WCF 端监视它)。

我们注意到 SSIS 在两台机器上的行为方式存在很大差异,我怀疑这就是问题的原因。两台 SSIS 机器都从服务下载相同的 WSDL 数据。然而,我的机器(功能性机器)上的 Web 服务任务与另一台开发人员的机器(非功能性机器)上有一组不同的输入。例如,如果我尝试调用的方法是 DoStuff(int data1,decimal data2, string msg),我将有 5 个输入:data1 (int), < code>data1Specified (bool)、data2(十进制)data2Specified (bool)msg (string) 而另一个机器缺少data1Specifieddata2Specified 输入。当使用其他输入时,似乎这个 xxxSpecified 变量总是由我的机器为除字符串之外的所有数据类型创建(未经过详尽测试,但已在其中抛出约 8 种数据类型),但其他开发人员的机器永远不会创建这些 xxxSpecified 变量。

还有一件事需要注意:如果另一个开发人员从我的机器导入 .DTSX 并直接运行它,它就可以工作。如果他单击“下载 WSDL”按钮,即使下载的是完全相同的 WSDL,他也会在指定要调用的服务/方法后获得一组不同的输入。显然他的 SSIS 开发环境正在做出与我不同的决定,我们无法弄清楚为什么或如何使他的行为更像我的。我们甚至没有意识到为什么这些 xxxSpecified 变量显然是必要的(“Specified”在 WSDL 中不存在)。

为什么 SSIS 生成这些 xxxSpecified 输入,以及为什么在一种环境中而不是在另一种环境中?

  • 说明:“GoodDevBox”从头开始手动创建项目,并且它可以工作(即具有xxx指定的输入)。 “BadDevBox”从头开始手动创建项目,但它不起作用(即缺少 xxxSpecified 输入)。该问题与共享项目/解决方案无关。事实上,如果“BadDevBox”不重新处理 WSDL,则共享它们是使其发挥作用的唯一方法。

I'm trying to consume some WCF services from SSIS. I had it working fine from a development machine. However, when another developer tries to do this, they have issues.

If the other developer copies my .DTSX file, then it works. However, if they create it themself, then it fails to connect (monitoring it from the WCF side).

We have noticed a BIG difference in how SSIS acts on the two machines and I suspect that is the cause of the problem. Both SSIS machines download the same WSDL data from the service. However, the Web Service Task on my machine (the functional one) has a different set of inputs than on the other dev's machine (the non-functional one). For example, if my method I was trying to call was DoStuff(int data1, decimal data2, string msg), I would have 5 inputs: data1 (int), data1Specified (bool), data2 (decimal), data2Specified (bool),and msg (string) whereas the other machine lacked the data1Specified and data2Specified inputs. When working with other inputs, it appears that this xxxSpecified variable is always created by my machine for all data types except for strings (not exhaustively tested but have thrown ~8 data types in there) but the other dev's machine NEVER creates these xxxSpecified variables.

One more thing of note: If the other dev imports the .DTSX from my machine and directly runs it, it works. If he clicks on the "Download WSDL" button, even though it downloads the exact same WSDL, he gets a different set of inputs after specifying the service/method to call. So apparently his SSIS development environment is making different decisions than mine is, and we can't figure out why or how to make his act more like mine. Nor do we even realize why these xxxSpecified variables are apparently necessary ("Specified" exists NOWHERE in the WSDL).

WHY does SSIS generate these xxxSpecified inputs, and why in one environment but not another?

  • Clarification: "GoodDevBox" creates the project manually, from scratch, and it works (i.e. has the xxxSpecified inputs). "BadDevBox" creates the project manually, from scratch, and it doesn't work (i.e. is missing the xxxSpecified inputs). The problem has nothing to do with sharing projects/solutions. In fact, sharing them is the only way to get this to work, if the "BadDevBox" doesn't reprocess the WSDL.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

撩起发的微风 2024-12-03 19:26:11

我的经验是,如果您有配置文件,或者您已经构建/编译了解决方案,它会将凭据和设置存储在配置文件中,包括网络凭据。

当将解决方案从一台计算机传递到另一台计算机时,它会将这些凭据保留在配置中,无论用户是否使用其登录名打开解决方案。

检查配置文件并比较有效和无效的配置文件

I have experienced that if you have config files, or if you have built/compile the solution it stores credentials and settings in the config file, including network credentials.

When passing solutions from one machine to another it keeps those credentials in the config, regardless if the user opens up the solution using their login.

Check the config file and compare them between the one that works and the one that doesn't

孤独岁月 2024-12-03 19:26:11

我们最终只是在有问题的计算机上卸载并重新安装 SQL Server,运行 Windows 更新,问题就消失了。仍然不知道问题是什么,也不知道我的问题的真正答案:为什么会生成名称末尾带有“指定”的变量。

We ultimately just uninstalled and reinstalled SQL Server on the problematic machines, ran Windows Updates, and the problem went away. Still have no idea what the problem was, nor do I still know the true answer to my question: WHY the variables with "Specified" at the end of the names are generated.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文