|
|
|
Arithmetic overflow error converting expression to data type int
|
|||
|---|---|---|---|
|
#18+
Очень не понятная ситуация: Reporting Services. Есть отчёт, основанный на хранимой процедуре (так же пробовал и view) в SQL Management Studio они (SP, view) выполняются без проблем и ошибок при любых условиях фильтрации. При попытке выполнения этой процедуры в отчёте (при разработке или опубликованного) при определённых входных параметрах процедуры (диапазон дат 01.07.2009 - 01.07.2009) результирующий набор не возвращается, а вываливается сообщение об ошибке: Код: plaintext 1. Самое обидное, что в результирующем наборе вообще нет целочисленных параметров - все float. Для пущей уверенности во всех выражениях, вычисляющих результирующие поля, поставил явные преобразования всех "членов" к float. Если этот же SQL текст оформить в виде view, в котором отсутствует предложение where, и из отчёта выполнять SELECT * FROM my_view, то все данные возвращаются без ошибок (в т.ч. и на 01.07.2009), стоит где нибуть (в отпределении view или в отчёте) добавить условие WHERE, выбирающее конкретную дату (01.07.2009) - отчёт падает с той же ошибкой (за другие даты не падает, иходные данные за этот день ничем принципиальным от других не отличаются, профайлером ничего не вылавливается - он считает, что запрос выполнен успешно). Если у кого есть какие идеи в чём тут может быть проблема и как её разрешить - помогите, плиз. Очень надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2009, 13:29 |
|
||
|
Arithmetic overflow error converting expression to data type int
|
|||
|---|---|---|---|
|
#18+
приведите запрос полностью. Проводить жизнь в ожидании мессии, который придёт и спасёт мир, всё-равно, что ждать палку в тетрисе. Даже если и появится, то ты к тому времени наберёшь такую гору дерьма, что те будет уже абсолютно пох... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2009, 16:52 |
|
||
|
Arithmetic overflow error converting expression to data type int
|
|||
|---|---|---|---|
|
#18+
Мне не жалко привести реальный запрос, только это не очень удобно - он достаточно большой и описание исходных таблиц ещё нужны... Врят ли кому будет охота с ним разбираться. Важно (на мой взгляд) то, что в SQL студии он выполняется всегда, в отчёте при отсутствии условий отбора выполняется и отображает все данные, а в отчёте при наличии условия y=2009 and m=7 падает по ошибке (при других условиях выполняется нормально). Вот "верхушка айсберга": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2009, 19:08 |
|
||
|
Arithmetic overflow error converting expression to data type int
|
|||
|---|---|---|---|
|
#18+
Проблему решить удалось - нашёл одно выражение в одном из подзапросов, где небыло явного преобразования int к float (его результат учавствовал в промежуточных расчётах и в результирующем наборе "чистого" этого параметра нет). Но почему ошибка вываливалась только если отфильтрован один конкретный месяц и только если запрос выполняется из ReportingServices я не понял. В найденном выражении числа учавствовали маленькие и результат после его (выражения) изменения не изменился. Если у кого есть варианты объяснения этого феномена - было бы интересно понять его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2009, 10:23 |
|
||
|
|

start [/forum/topic.php?fid=31&msg=36068531&tid=1536082]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
133ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 198ms |
| total: | 389ms |

| 0 / 0 |
