|
"длинная строка"
|
|||
---|---|---|---|
#18+
Использую вот такой код: 2.rar Ранше все нормально работал, добавил несколько поле после етого не работает. Если удалит название несколких полей из программы, тогда работает. Значить, получается "длинная строка". Помогите пожалуйста, как можно грамотно написаит такой код? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 08:57 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
q1q2q3Использую вот такой код: 2.rar Ранше все нормально работал, добавил несколько поле после етого не работает. Если удалит название несколких полей из программы, тогда работает. Значить, получается "длинная строка". Помогите пожалуйста, как можно грамотно написаит такой код? А код где ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 09:20 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
сруктура Вашей таблицы - это ярчайший пример ... нет желания что-то изменить? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 09:38 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
прошелмимосруктура Вашей таблицы - это ярчайший пример ... нет желания что-то изменить? Нет, лучше структуру таблицу не трогать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 09:41 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
ну понятно, конструируем лисапед с нажиматором и не ищем легких путей. как пример, демонстрирующий, что проблемы решаются просто и надежно автор INTO CURSOR prix_ksk ERASE prix_ksk.DBF вот это пишется сразу Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 09:46 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
к сведению на 9-ке при установки set enginebehavior 70 это все отработало ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 09:57 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
ыыыыыы - Мама роди меня обратно !!! Сохранил у себя как пример "как не надо делать." прошелмимок сведению на 9-ке при установки set enginebehavior 70 это все отработало Аналогично. Так что уточните версию фокса и что значит не работает как вариант Код: plaintext 1. 2.
Ну и все-таки стоит пересмотреть структуру таблиц , один раз переписать всё это безобразие и забыть как дурной сон. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 11:48 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
-=AlexiS=-ыыыыыы - Мама роди меня обратно !!! Сохранил у себя как пример "как не надо делать." прошелмимок сведению на 9-ке при установки set enginebehavior 70 это все отработало Аналогично. Так что уточните версию фокса и что значит не работает как вариант Код: plaintext 1. 2.
Ну и все-таки стоит пересмотреть структуру таблиц , один раз переписать всё это безобразие и забыть как дурной сон. У меня VFP6 и у меня этот код тоже не работает. А в структуре таблицы что не так? Что нужно менять? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 14:03 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
VFP9 работает. Этот код как как можно переделать, так что и VFP6 тоже работал? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 15:24 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
ну тогда попробуйте за 2 прохода 1 получите отдельные поля по каждой из составляющей SELECT BUX.q_kod,q_koshk,q_alish,q_ad,q_sk,sum(abun) as abun, ..... sum(fil12) as fil12 ,Q_N; FROM BUX; WHERE Q_SK=0; GROUP BY BUX.q_kod,q_koshk,q_alish; INTO CURSOR prix_ksk 2 потом сложите в одном поле все эти составляющие select BUX.q_kod,q_koshk,q_alish,q_ad,q_sk,abun+....+fil12 ,Q_N; ******************* А насчет того что менять - ну тут очень много писать надо. Советую Вам сначала почитать про нормализацию БД а кратко - вам нужно превратить ваши таблички из "горизонтальных" в "вертикальные" ну на простейшем примере (как я понял из приложенной таблицы- у вас нечто похожее) Пусть у нас есть 2 склада , на который мы храним что-то делаем таблицу Товар / количество_Склад 1 / количество_Склад 2 Радостно ведем в ней учет общее количество по складам получаем количество_Склад 1 + количество_Склад 2 Но в один прекрасный момент времени у нас появляеться еще один склад ХА , не вопрос - лупим еще поле количество_Склад 3 Теперь общее количество по складам получаем количество_Склад 1 + количество_Склад 2 + количество_Склад 2 Ищем по всем программам и отчетам правим и радуемся. Но зловредное начальство не унимаеться , открывает все новые склады, мы матюкаемся, добавляем поля, исправляем формы ввода , программы и репорты . Не успеваем к сроку- получаем за это "по шапке". И это все вместо того чтобы попивая чаек-кофеек сидеть в интернете. Короче страх и ужОс. Собственно это то что реализовано у вас. А что-же нужно было сделать Да все просто табличку создаем вида Код_Товара / Код_Склада / Количество Ну и таблички-справочники с названиями. Добавляем новый склад - ничего менять не нужно , только в справочник складов добавить Сумму по складам получаем с помощью group by Код_Склада общую - вообще без групировок Сводную ведомость по складам - с помощью Cross-таблицы Все делаем один раз . При вводе нового склада говорим начальству - охринеть -работы навалило, но вместо того чтобы лихорадочно рыться по проекту - сидим в интернете , читаем форум. Все это очень сильно упрощенно , но идея думаю понятна. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 16:04 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
Попробуй разбить суммирование на части примерно так: Код: plaintext
Идея заключается в том, чтобы уменьшить количество слагаемых внутри одного выражения SUM(), а по окончании суммирования сложить результаты. Также возможно (хотя и не уверен), может помочь SYS(3055) q1q2q3А в структуре таблицы что не так? Что нужно менять? "Не так" вот это безумное количество однотипных полей. "Однотипных" по той причине, что возникла необходимость в их суммировании. Это указывает на серьезные ошибки проектирования базы данных (не данной таблицы, а всего комплекса данных в приложении). В грамотно спроектированном прилоежнии просто не должно возникать подобных задач. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.03.2009, 16:07 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
Проверил на VFP6SP5 разложение на несколько SUM() дает вполне нормальный результат Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Если делать через одно выражение SUM(), то вылет происходит при добавлении 103 слагаемого. Длина выражения из 102 слагаемых = 729 символов, а из 103 слагаемых = 737 символов 102 слагаемое - это beylagan, а 103 - это shirvan Причем, если не использовать выражение SUM(), то вылет произойдет при превышении 254 символов в макроподстановке. Т.е. есть какое-то внутреннее (не документированное) ограничение на длину выражения макроподстановки внутри агрегатных функций. PS: все-равно, какое-то "безумное" выражение получается ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2009, 00:12 |
|
"длинная строка"
|
|||
---|---|---|---|
#18+
[necropost(?)] А мне "в наследство" похожая медвежуть досталась. Пока не нормализовал (походу проще будет с нуля всё сделать :) ), но пока что лень сподвигла написать доп. табличку с кодами полей и практически все выборки делать по ней. Типа так //fieldnames (kod C(10)) fsum=0 select fieldnames scan tmpvar='имяаццкойтаблицы.'+trim(fieldnames.kod) fsum=fsum+&tmpvar endscan Жесть (и у меня табличка посложней, но не в том суть), но в сравнении с тем, что было, - сказка :lol: ВладимирМЭто указывает на серьезные ошибки проектирования базы данных (не данной таблицы, а всего комплекса данных в приложении). В грамотно спроектированном прилоежнии просто не должно возникать подобных задач. Так то в грамотно спроектированном... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2009, 19:14 |
|
|
start [/forum/moderation_log.php?user_name=Rb]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
others: | 912ms |
total: | 1107ms |
0 / 0 |