Почему этот SQL не работает как хранимая процедура, но отлично работает как обычный запрос?

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

Edit:

Оказывается, что к числу добавляются нули, в конце которых: 33.832200000000000

Этого никогда не было, потому что я не уверен, что изменилось. Они добавляются при запуске prcedure.

Answer 1

Держу пари, что это связано с проблемой конверсии. Действительно ли в вашей таблице TrackingData.lattitude и TrackingData.longitude десятичные (18,15)?

Вы можете заменить параметры в SP двумя значениями в первом запросе и получить ответ обратно? Если так, то это когда-то в преобразовании, когда вы передаете параметры в.

Answer 2

ОК, поэтому я изменил параметры Lat и Long на тип FLOAT. Теперь работает отлично. Я не думал, что при отправке параметров в виде десятичного числа (18,15), это добавит нули в конец, если точность будет меньше 15. Спасибо всем, кто помог с этим.

Answer 3

Что это дает вам вне хранимого процесса?

...
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 4

Так же, как и к вашему сведению, широта и долгота, имеющие пятнадцать знаков после запятой с точностью после запятой, почти наверняка превышают точность. Рядом с экватором точность в шесть цифр соответствует разрешению 11 сантиметров (4,3 дюйма). Еще девять порядков на пути к точности молекулярного размера ...

Answer 5

Я все время работаю с Латом и Лонгом, и в качестве типа данных я использовал DECIMAL (18,15).

У меня тоже была такая проблема: (

Для меня это была проблема с ЛОКАЛИЗАЦИЕЙ -> когда пользователь из не-en-us / en-gb и т. Д. Местоположения попал на мой сайт, PERIOD был заменен на COMMA. поэтому я пытался передать 123,111 для десятичного значения. потерпеть поражение. Это означает, что в моем .NET-приложении текущее значение CultureInfo текущего потока автоматически настраивалось на язык подключения пользователя (например, es для Испании и т. Д.).

.
(для продукта / проекта .NET) ....

Попытайтесь убедиться, что вы установили для Cultureinfo потока значение en-gb (это все-таки правильный английский, в конце концов ... swipe!), А затем посмотрите, работает ли сохраненный процесс.

Слишком я -aaaaaagggggeeeeesssssss-, чтобы исправить эту ошибку :) Вы видите, она всегда работала на моей локальной машине (en-au) и как запрос ...:)

удачи:)

Answer 6

У вас есть доступ к SQL Server Profiler? Если это так, я бы рекомендовал отследить, что фактически передается в функцию execute в качестве параметров. Возможно, есть проблема точности со значениями, передаваемыми в SP. Вы думаете, что это 131, но вместо этого вы получаете 131,00000000000000000000000000001.