Хранимая процедура с плавающим значением усечения входного параметра - PullRequest
0 голосов
/ 17 апреля 2011

У меня есть хранимая процедура с входными параметрами:

  @Latitude float
, @Longitude float

но когда я передаю эти значения:

 @Latitude=-28.640328248358344
,@Longitude=153.61249352645871

значения, хранящиеся в таблице:

Lat: -28.6403
Lng: 153.612

Если я делаю стандартную вставку или обновление таблицы, значения верны.

Я попытался изменить параметры на float (54), но это не имело никакого значения ... Причина, по которой я использую float, заключается в том, что Lat / Lng на самом деле вычисляются как столбцы из столбца географии (и в конструкторе говорится, что они являются числами с плавающей точкой) - я дважды проверил, что это не связано с вычисляемыми столбцами, вставив значения lat / lng из хранимой процедуры в пару столбцов varchar.

Я использую EF и могу подтвердить, что значения в Entities верны, и я проверил SQL Profiler, чтобы убедиться, что полные значения включены в вызов exec.

EDIT: Я вставляю эти значения в вызов столбца GeoLocation типа geography:

GeoLocation = geography::STPointFromText('POINT(' + CONVERT(varchar, @Longitude) + ' ' + CONVERT(varchar, @Latitude) + ')',4326)

Ответы [ 2 ]

3 голосов
/ 17 апреля 2011

Когда вы применяете float к varchar, вы теряете точность.Используйте STR для преобразования в varchar

Комментарий гласит "CONVERT (varchar, @Longitude)".Это не «усечение ввода», а нормальное поведение

1 голос
/ 17 апреля 2011

Попробуйте:

DECLARE @Longitude FLOAT = 41.1234567

SELECT CAST(@Longitude AS VARCHAR(24))

Каков ваш результат ??В моем случае кажется, что SQL Server всегда будет усекать до четырех цифр после десятичной запятой .....

Может ли быть причиной вашего усечения ??Это действительно только преобразование в VARCHAR, которое вызывает усечение ??Попробуйте сохранить значения в вашем sproc как FLOAT и посмотрите, усекаются ли эти значения тоже - я уверен, что они не будут!

...