Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Делаю запрос Код: plaintext в SQL Server и FP. Содержание таблиц идентичное, размерность поля numeric(15, 2) в FP и (10, 2) в SQL Server. Запросы выдают разный результат. Почему может быть такое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2004, 13:23 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Код: plaintext а где волшебная фраза group by ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2004, 13:30 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Hi coolkenga! Во-первых N(10,2) в MS SQL это не то-же самое что N(10,2) в фоксе!!! в фоксе считается и точка, и минус за "содержимое" поля, в MS SQL насколько я в курсе нет (в Oracle точно нет). Во-вторых ты так и не сказала в чём именно проявляется "разность" результатов. В фоксе есть прибабах, когда подобный запрос (а также COUNT(SomeField) запрос) для пустых таблиц, или таблиц заполненных только null-ами возвращают пустой результат (0 строк!). Тогда как по стандарту должны таки дать одну строку с 0 в ней. Также может быть проблема в "понимании" фоксом разделителя (десятичной точки) - сервер может и точку слать и запятую (от настроек сервера и коннекции зависит) а фокс понимает лишь точку. В-третьих ты не сказала как именно работаешь с сервером из FPD... Может там собака зарыта? 2 Sergey - а тут Group by не нужен :) мы считаем результат по ВСЕМ записям. Конечно если запрос приведен ДОСЛОВНО. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2004, 22:40 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Может в FP в суммировании принимают участие записи, помеченные на удаление? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2004, 01:01 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Во-первых N(10,2) в MS SQL это не то-же самое что N(10,2) в фоксе!!! в фоксе считается и точка, и минус за "содержимое" поля, в MS SQL насколько я в курсе нет (в Oracle точно нет). В этом поле нет больших (>99999) и отрицательных значений. Igor Korolyov Во-вторых ты так и не сказала в чём именно проявляется "разность" результатов. В Фоксе сумма получается больше, чем в SQL. Igor Korolyov В фоксе есть прибабах, когда подобный запрос (а также COUNT(SomeField) запрос) для пустых таблиц, или таблиц заполненных только null-ами возвращают пустой результат (0 строк!). Тогда как по стандарту должны таки дать одну строку с 0 в ней. Также может быть проблема в "понимании" фоксом разделителя (десятичной точки) - сервер может и точку слать и запятую (от настроек сервера и коннекции зависит) а фокс понимает лишь точку. В-третьих ты не сказала как именно работаешь с сервером из FPD... Может там собака зарыта? Таблицы 2 - одна на SQL сервере, другая dbf в FP, данные из таблицы переносятся один в один приложением. Т.е. коннекта к серверу из FP нет, считаю отдельно в FP и в SQL. Они обе непустые. Igor Korolyov 2 Sergey - а тут Group by не нужен :) мы считаем результат по ВСЕМ записям. Конечно если запрос приведен ДОСЛОВНО. Да, дословно. CALC SUM ... TO выдает тот же самый результат, что и селект в фоксе, т.е бОльшую цифру, чем SQL. Может в FP в суммировании принимают участие записи, помеченные на удаление? Количество записей одинаково в обеих таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2004, 09:32 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Слушай, посчитай столбиком. Я серьезно. Первое подозрение, это что твои таблицы на SQL-сервере и в DBF имеют разное содержимое. Одинаковое количество строк не гарантия одинакового содержимого. Кроме того, vl2000 имел в виду записи помеченные как удаленные в DBF, но которые физически еще не удалены. В этом случае на результат суммирования в FoxPro будет влиять настройка SET DELETED ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2004, 15:03 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
В Фоксе сумма получается больше, чем в SQL. Ну если все приведено дословно то остается только попробовать: Код: plaintext Или что-то в таком духе, что советует Владимир - самый надежный способ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2004, 16:56 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Hi coolkenga! Индекс есть? Попробуй пересоздать - может он побился и как-то влияет... Также неплохо бы проверить (если возможно) и саму таблицу на предмет наличия там "непонятных" записей - может повредилась сама таблица? Какое именно расхождение (абсолютная его величина, а заодно и скажи количество записей - чтоб оценить варианты) - т.е. не может ли это быть ошибками округления или ещё чем-то таким? Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 04:07 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
ВладимирМСлушай, посчитай столбиком. Я серьезно. Первое подозрение, это что твои таблицы на SQL-сервере и в DBF имеют разное содержимое. Одинаковое количество строк не гарантия одинакового содержимого. Кроме того, vl2000 имел в виду записи помеченные как удаленные в DBF, но которые физически еще не удалены. В этом случае на результат суммирования в FoxPro будет влиять настройка SET DELETED Записей помеченных на удаление нет и запрос Код: plaintext Столбиком - трудновато, записей от 40 тыс до 86 тыс... Igor KorolyovИндекс есть? Попробуй пересоздать - может он побился и как-то влияет... Также неплохо бы проверить (если возможно) и саму таблицу на предмет наличия там "непонятных" записей - может повредилась сама таблица? Какое именно расхождение (абсолютная его величина, а заодно и скажи количество записей - чтоб оценить варианты) - т.е. не может ли это быть ошибками округления или ещё чем-то таким? Индекса нет. записей 86 тыс - расхождение 35,54 записей 40 тыс - расхождение 0,22 записей 77 тыс - расхождение 0,94. Если это ошибки округления, как это проверить и обойти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 12:37 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Примерно так: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 13:48 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
UrriПримерно так: Код: plaintext Это где? В FP? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 14:48 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Ну да ;-) И то же самое в SQL (ну, синтаксис другой, может быть). Если такие функции разрешены, конечно ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 15:09 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
UrriНу да ;-) И то же самое в SQL (ну, синтаксис другой, может быть). Если такие функции разрешены, конечно ;-) Все то же самое. Результат очень незначительно меняется в FP. Похоже придется и правда столбиком считать. :) Спасибо за участие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 15:29 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Вспомнил - попробуйте поменять значения для установки: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 16:37 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Sergey ChВспомнил - попробуйте поменять значения для установки: Код: plaintext А это разве это влияет не только на отображение знаков после запятой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 17:20 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Ну, чтоб меньше считать было, сожет, действительно данные как-то отгруппбаить (от group by)? А потом посмотреть, в каких именно группах несоответствие и уже по ним столбиком считать. (Это как количество взвешиваний в задаче про 9 шаров, из которых один тяжелее остальных.) ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 17:26 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
UrriНу, чтоб меньше считать было, сожет, действительно данные как-то отгруппбаить (от group by)? А потом посмотреть, в каких именно группах несоответствие и уже по ним столбиком считать. (Это как количество взвешиваний в задаче про 9 шаров, из которых один тяжелее остальных.) ;-) Да, похоже только это и остается, SET DECIMALS TO не помогло... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 17:58 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Возник попутный вопрос - можно в FP отобрать записи по их конкретно заданным номерам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 18:29 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
если имеется ввиду номер записи в таблице и выборка по одной таблице то как то так select * from table1 into cursor mycursor where recno() in (1,2,3,4) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2004, 18:38 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Hi coolkenga! > записей 86 тыс - расхождение 35,54 > записей 40 тыс - расхождение 0,22 > записей 77 тыс - расхождение 0,94. Вполне может быть ошибка округления. Попробуй такой запрос SELECT * FROM table1 WHERE field1 # ROUND(field1,2) и посмотри вернёт ли он чего-нить... В принципе если бы поле было не Numeric а Double - то это 100% были бы ошибки округления. У Double поля есть такая пренеприятная особенность - он хранит одно значение, а показывает совсем другое :) Урезанное до нужного числа знаков. А на разных операциях с участием такого поля и вылазит всякая ерунда :) На 86000 записей при точности в 2 знака после запятой, в самом неприятном случае можно получить погрешность заметно больше чем есть у тебя :) Вплоть до 429.99 :) Если скажем каждая запись физически имеет вид xxx.xx49999 Кстати в MS SQL числовой тип не соответствует ли фоксовому Double? В смысле хоть и указано в формате что есть тока 2 знака, а реально он хранит большую точность? Попробуй и в MS SQL запрос с округлением проверить. В крайнем случае просто посчитай SUM(Field1*10000) и посмотри где будет сумма не делящаяся на 100 нацело :) Там скорее всего и работает "невидимая" дополнительная точность. Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2004, 03:20 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Снова вспомнил! Как у Вас FPD 2.6 запускается? Как приложение или Вы проверяете запрос из окна COMMAND? Если как приложение - то надо как compact EXE плюс большую библиотеку (если делать большой EXE то тут у FPD есть проблема с армфметикой - считает действительно неправильно). Последняя идея. Считать в ручную такое количество сложно... Для VFP 8.0 провести запрос - если результат снова неправильный, то сравнить две таблицы на SQL и FPD - тогда видно будет, где проблема . Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2004, 12:31 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Если количество строк совпадает (т.е. фактически одни и те же данные), то проверяется элементаторно. Делаются два запроса: один к базе Фокса, другой на СКЛ сервер (основное условие, что бы была одинаковая сортировка. желательно по ключевому полю). Потом результаты обеих запросов кидаем в Эхель (COPY TO .... TYPE XL5). Совмещаем их на одном листе, проверяем совпадение строк, и если ключевое поле совпадает- пишем формулку = A1 - C1 где А1 и С1 ячейки с суммами. Тянем формулу до саамого низу. Смотрим где получился не 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2004, 17:30 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
vl2000Если количество строк совпадает (т.е. фактически одни и те же данные), то проверяется элементаторно. Делаются два запроса: один к базе Фокса, другой на СКЛ сервер (основное условие, что бы была одинаковая сортировка. желательно по ключевому полю). Потом результаты обеих запросов кидаем в Эхель (COPY TO .... TYPE XL5). Совмещаем их на одном листе, проверяем совпадение строк, и если ключевое поле совпадает- пишем формулку = A1 - C1 где А1 и С1 ячейки с суммами. Тянем формулу до саамого низу. Смотрим где получился не 0. Это Вы явно погорячились. Такое не пройдет по нескольким причинам: 1) В Excel предельно допустимое количество строк около 65500, а в таблицах 86000 записей. Просто не поместятся в Excel 2) Как Вы себе представляете визуальный просмотр такой тучи строк? В теории все прекрасно, но на практике глаза начнут слипаться уже к конце первой тысячи. 3) Наконец, существуют более простые способы сравнения содержимого 2 таблиц. Например, качаем таблицу с SQL сервера в FoxPro. Делаем объединение по FULL JOIN с таблицей DBF и смотрим разницу. В выборку попадают только те записи, где есть отличия. Правда, такой способ сравнения не учитывает разные форматы хранения данных в SQL и FoxPro. Конечно, если проблема именно в этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2004, 18:56 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Я не думаю что погорячился. Разбиваем запросы на два (будем сравнивать в 2-х файлах, например: 1-40000, 40001-80000). Визуально сравнивать не надо вообще. Пишем формулу разности двух ячеек. Потом ставим фильтр на значения, отличные от 0. Да, вначале так проверяем совпадение ключевого поля. Если в поле проверки все 0, ту же операцию проделываю по проблемному полю (по которому не идет сумма). В некоторых случаях такой способ наиболее удобен. По крайней мере я им иногда пользуюсь. Правда я работаю с InerBase через IBExpert. Из него напрямую передаю данные в Эхель, не знаю, возможно ли так сделать в MSSQL. Таким образом я исключаю влияние VFP на данные SQL сервера (при их получении). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2004, 00:51 |
|
||
|
sum в FP под DOS и SQL Server
|
|||
|---|---|---|---|
|
#18+
Hi vl2000! Пользоваться можно много чем :) Но по мне так из фокса заметно проще и быстрее будет. Конечно если опыта в фоксе 0, то лучше и не соваться. > В некоторых случаях такой способ наиболее удобен. Именно что в некоторых. > Таким образом я исключаю влияние VFP на данные SQL сервера (при их > получении). И добавляешь влияние Excel и IBExport или иной тулзы через которую получил данные :) Опять же если ты хорошо знаком с фоксом, то ты ЗНАЕШЬ что и как могло повлиять, если НЕ ЗНАКОМ с IBExport или иными средствами, то НЕ ЗНАЕШЬ что в НИХ могло повлиять... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2004, 04:11 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=32796259&tid=1595283]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
88ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
85ms |
get tp. blocked users: |
2ms |
| others: | 264ms |
| total: | 493ms |

| 0 / 0 |
