Question

TrackingData表位于名为Tracking的数据库中。存储过程正在同一数据库中运行。我使用查询返回数据，但不是SP。

SELECT *
    FROM
      dbo.TrackingData
      LEFT OUTER JOIN SSMain.dbo.EmailCampaignTracking ON (dbo.TrackingData.emailCampaginTrackingID = SShMain.dbo.EmailCampaignTracking.emailCampaignTrackingID)
      LEFT OUTER JOIN SSMain.dbo.EmailCampaigns ON (SSMain.dbo.EmailCampaignTracking.emailCampaignID = SSMain.dbo.EmailCampaigns.emailCampaignID)
      LEFT OUTER JOIN SpinStitchMain.dbo.EmailListAddresses ON (SSMain.dbo.EmailCampaignTracking.emailAddressID = SSMain.dbo.EmailListAddresses.emailAddressID)
    WHERE
      dbo.TrackingData.lattitude = 33.8322 AND 
      dbo.TrackingData.longitude =  -78.6491 and
      dbo.TrackingData.projectID = 131

CREATE PROCEDURE dbo.sel_Track_HitsByLatLong(
@latitude decimal(18,15),
@longitude decimal(18,15),
@projectID int
)
AS
BEGIN
 SELECT *
FROM
  dbo.TrackingData
  LEFT OUTER JOIN SSMain.dbo.EmailCampaignTracking ON (dbo.TrackingData.emailCampaginTrackingID = SSMain.dbo.EmailCampaignTracking.emailCampaignTrackingID)
  LEFT OUTER JOIN SSMain.dbo.EmailCampaigns ON (SSMain.dbo.EmailCampaignTracking.emailCampaignID = SSMain.dbo.EmailCampaigns.emailCampaignID)
  LEFT OUTER JOIN SSMain.dbo.EmailListAddresses ON (SSMain.dbo.EmailCampaignTracking.emailAddressID = SSMain.dbo.EmailListAddresses.emailAddressID)
WHERE
  dbo.TrackingData.lattitude = @latitude AND 
  dbo.TrackingData.longitude = @longitude and
  dbo.TrackingData.projectID = @projectID
END

编辑：

原来这些数字在他们的末尾添加了零：33.832200000000000

从来没有发生过这样的事情。它们在运行时被添加。

Answer 1

我敢打赌它与转换问题有关。 TrackingData.lattitude和TrackingData.longitude在您的表格中是十进制（18,15）吗？

您可以使用第一个查询中的两个值替换SP中的参数并获得答案吗？如果是这样，那么当您传递参数时，它就在转换中的某个位置。

Answer 2

我一直与Lat和Long一起工作 - 我曾经使用DECIMAL（18,15）作为数据类型。

我也有这个问题:(

对我来说，这是一个LOCALIZATION问题 - ＆gt;当来自非en-us / en-gb等位置的用户访问我的网站时，PERIOD被替换为COMMA。所以我试图传入123,111的十进制值。失败。这意味着，在我的.NET应用程序中，当前线程的CultureInfo被自动设置为用户连接的区域设置（例如，es用于西班牙等。）

。
（对于.NET产品/项目）....

尝试确保你将线程的cultureinfo设置为en-gb（毕竟是正确的英文...刷卡！）然后查看存储的proc现在是否有效。

Too me -aaaaaagggggeeeeesssssss-修复那个bug :)你看，它总是在我的本地机器上工作（en-au）并作为查询... :)

祝你好运：）

Answer 3

就像一个FYI一样，纬度和经度在十进制之后具有十五位十进制数字几乎肯定是超精确度。在赤道附近，六位数的精度对应于11厘米（4.3英寸）的分辨率。在分子尺寸精度的方向上，已经有九个数量级了......

Answer 4

这会在存储过程之外给你带来什么？

...
WHERE
  dbo.TrackingData.lattitude = CAST(33.8322 as decimal(18,15)) AND 
  dbo.TrackingData.longitude =  CAST(-78.6491 as decimal(18,15)) and
  dbo.TrackingData.projectID = CAST(131 as int)

然后将此存储过程

添加

SELECT @latitude, @longitude, @projectID

在此之间，你应该看到存储过程正在使用什么以及当数据类型匹配时查询返回的内容

Answer 5

您是否可以访问SQL Server探查器？如果是这样，我建议捕获一些实际传递给执行函数的内容作为参数。传递给SP的值可能存在精度问题。你认为它的131，但你得到的是131.00000000000000000000000000001。

Answer 6

好的，所以我将Lat和Long参数更改为FLOAT类型。它现在完美无缺。我没有想到在将参数发送为十进制（18,15）时，如果精度低于15，它会在末尾添加零。感谢所有帮助过这个的人。

为什么这个SQL不能作为存储过程工作，但作为常规查询工作正常？

6 个答案: