试图诊断一个问题，我遇到了这种不一致。在 SQL Server Profiler 中，RPC Starting事件使用区域设置来写入实数（例如：在葡萄牙语（巴西）14.5 中将表示为 14,5）。通常这不是问题，除非 RPC 调用是带有实数参数的存储过程。那么期望表达为：
exec usp_something 'blabla', 14.5
表示为：
exec usp_something 'blabla', 14,5
当你有一个很长的参数列表时，这会让人很头疼。没有在网上找到任何线索如何改变这种行为。
有人知道改变这种行为的方法吗？
顺便说一句：我知道解决方法是改用SP Starting事件，它使用 '.' 为小数点分隔符。
嗯，这是假设的场景，但我想了解的是从死后日志（例如 SQL Server Profiler 跟踪）到识别 ORM 情况下的代码的路径。为了让它不会太模糊，请考虑这样的场景：
那么，在这种情况下，DBA（也是 VB.Net 开发人员）从日志中诊断哪些代码（在这种情况下，Linq 查询）造成问题的通用路径是什么？在这种情况下，该应用程序正常，但会影响使用相同数据库/服务器的其他应用程序的响应时间。
那会与 Java+Hiberate 进程有很大不同吗？
编辑：我想了解从跟踪到罪魁祸首元查询的路径。如果应用程序中有 SQL，这意味着“在文件中查找”会话（在极端情况下可能带有一些正则表达式）可以将检查任务的目标减少到几十个可疑对象，而不是十分之一甚至数百个源文件。使用 ORM，如何使用 ORM（在这种情况下：EF）到达那个阶段？