让 Visual Studio 执行 SQL 查询
在办公室中，我们使用 Visual Studio 2008 和 Team Foundation Server 作为我们的版本控制系统。
我们正在开发的产品本质上是 Teradata SQL 脚本和存储过程，它们通过自动调度程序部署在组织的 Teradata 数据库上运行。
我们遇到的问题：
每当我们需要修复缺陷或交付更改时，我们都会签出代码，将其复制到另一个工具来进行更改，然后一旦我们满意，我们就会检查它返回到 TFS。如果能在 Visual Studio 中完成所有操作，那就太棒了，但我们首先需要找到一些解决方案：
- SQL 语法突出显示
- 执行 SQL 脚本的能力 （将Teradata 的 .NET 数据提供程序 可以完成这项工作吗？）
- 参数替换
当然可以以某种方式完成语法突出显示和 SQL 执行，但我我特别担心参数替换会成为阻碍，因为我从未听说过 Visual Studio 做过这样的事情。
如何使用参数替换：
对于参数替换，我们需要能够使用数据库名称参数（或任何文本），以便在执行时对于 SQL，Visual Studio 基本上将代码中的参数替换为我们所连接的数据源所需的任何参数，无论是开发、测试还是生产环境。
例如，我们可能有这样的查询：
SELECT Client_Id, First_Name, Last_Name
FROM <<Client Database>>.Client_Names
当我们从 Visual Studio 执行该查询时，我们需要它进行参数替换，因此在幕后，以下是实际发送到数据库服务器的内容：
SELECT Client_Id, First_Name, Last_Name
FROM Client.Client_Names
同样，如果我这样做：
SELECT '<<Client Database>>'
当连接到生产服务器时，它将返回'Client'结果。
另一方面，如果我连接到开发服务器，它将返回'DevA_Client'。
我们当前用于执行此操作的工具仅具有 CSV 文件（即 Prod-params.csv）中定义的值的参数。然后，工具中有一个设置可将 Prod-params.csv 链接到生产数据源连接。此 CSV 文件的示例如下：
<<Client Database>>,Client
<<Order Database>>,Order
<<SomeHistoricDate>>,CAST('1997-05-28' AS DATE)
我希望有人能够为我指明方向，以便我能够在 Visual Studio 中执行这些操作。
In the office we use Visual Studio 2008 with Team Foundation Server as our version control system.
The products we're developing are essentially Teradata SQL scripts and stored procedures that get deployed to run on the organisation's Teradata database via an automated scheduler.
Problem We Have:
Whenever we need to fix a defect or deliver a change, we check-out the code, copy it to another tool to make our changes, then once we're happy, we check it back into TFS. It would be brilliant to do everything in Visual Studio, but there are a few solutions we need to find first:
- SQL Syntax Highlighting
- Ability to Execute SQL Scripts (will Teradata's .NET Data Provider do the job?)
- Parameter Substitution
Surely syntax highlighting and SQL execution can be done somehow, but I'm particularly worried that the Parameter Substitution will be the blocker as I've never heard of Visual Studio doing anything like this.
How we use Parameter Substitution:
For parameter substitution, we need the ability to use a parameter for our database names (or any text for that matter), so that when we execute the SQL, Visual Studio basically substitutes the parameters within the code to whatever we need for the data source we're connected to, whether it's a Development, Test or Production environment.
For example, we may have the query:
SELECT Client_Id, First_Name, Last_Name
FROM <<Client Database>>.Client_Names
When we execute that from Visual Studio, we need it to do parameter substitution, so behind the scenes, the following is what's actually sent to the database server:
SELECT Client_Id, First_Name, Last_Name
FROM Client.Client_Names
In the same way, if I do:
SELECT '<<Client Database>>'
It would return a result of 'Client' when connected to the Production server.
On the other hand, if I'm connected to the Development server, it would return 'DevA_Client'.
The tool we currently use to do this simply has the parameters with the values defined in a CSV file (i.e. Prod-params.csv). Then there's a setting in the tool to link Prod-params.csv to the Production data source connection. An example of what this CSV file looks like is:
<<Client Database>>,Client
<<Order Database>>,Order
<<SomeHistoricDate>>,CAST('1997-05-28' AS DATE)
I'd love someone to be able to point me in the direction to be able to do any of this stuff in Visual Studio.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您所描述的所有任务都可以通过编写 Visual Studio AddIn 包来完成，甚至是语法高亮，但这并不是一项简单的任务。无论如何尝试从这里开始： http://msdn.microsoft.com/en- us/library/bb166533.aspx 。基本上你可以通过扩展 VS 来完成所有事情，因此参数替换也应该很容易。此外，如果您的目标数据库有一个有效的 .NET 提供程序，那么最终执行查询应该是更简单的任务。
All the task you arfe describing can be done by writing a Visual Studio AddIn package, even the syntax higligthing, but is not a trivial task. Anyway try to start from here: http://msdn.microsoft.com/en-us/library/bb166533.aspx . Basically you can do everithing by extending VS, so parameter replacement should be easy as well. Additionally, if you have a working .NET provider for your target db eventually executing the query should be the simpler task.