Отправлено: 30.04.10 10:34. Заголовок: Как сделать программу 64битной ?
Всем привет ! Только не пинайте сильно за вопрос... Пока только разбираюсь....
Как готовое приложение под хХарбором (терминалка) пересобрать на 64bit под новые системы Win 7 ? Оно конечно и так там работает, но хотелось бы узнать что это даст ?
По ID-абонента, seek-ом иду на БД-оплаты-20хх года.
SELECT PLATA2011 DBSETORDER(1) GOTO TOP SEEK (ID-абонента)
Pasha пишет:
цитата:
Что записывается в оплаты и как, каким методом ?
После расчета, запись массива WritDimDbf(aMassiv,.F., @cError) Скрытый текст
********************************************************* FUNCTION WritDimDbf(aMassiv,lSee,cError) LOCAL cTemp, nJ, nSum, nY:=MAXROW(), nX:=0, nRazr DEFAULT lSee TO .T.
cError := "" FOR nJ := 1 TO 30
IF lSee cTemp:="Записываю записи: "+STR(nJ,2) @ nY,nX SAY PADC(cTemp,80) COLOR("14/5") ENDIF
cTemp:="Tarif"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_TARIF] // Тариф "N" , 6,2
nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF
cTemp:="TarDat"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_TARDAT] // Дата Тарифа "D" , 8,0
cTemp:="Prixod"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) nSum := aMassiv[nJ,A_PRIXOD] // Приход "N" , 6,2 nRazr:= FIELDSIZE(FIELDNUM(cTemp)) IF nRazr < LEN(ALLTRIM(STR(nSum))) cError:=cError+'Нехватает разрядности поля "'+cTemp+'" <-'+STR(nSum)+; " [размерность поля ="+; ALLTRIM(STR(nRazr))+" - размерность запис.значения ="+; ALLTRIM(STR(LEN(ALLTRIM(STR(nSum)))))+"]"+CRLF FIELD->&cTemp := -1 ELSE FIELD->&cTemp := nSum ENDIF
cTemp:="PriDat"+IIF(nJ<10,"0"+STR(nJ,1),STR(nJ,2)) FIELD->&cTemp := aMassiv[nJ,A_PRIDAT] // Дата Прихода "D"
Забыл еще уточнить. Сумма начислений (приход денег и начисления денег и долг) по каждому абоненту еще сохраняются и отдельно по каждому подъезду, за каждый месяц заносятся в БД-Договоров.
Отправлено: 05.12.11 22:45. Заголовок: Я уже устал напрягат..
Я уже устал напрягать свои и без того неразвитые телепатические способности :) Итак, что же мне удалось расшифровать: Имеется широоооокая таблица (не БД, давай все-таки использовать общепринятую, а не безграмотную терминологию) абонентов, назовем ее TA. Что хранится в ТА ? Все данные со всеми начислениями за все годы ? В чем заключается расчет ? Имеется какая-то таблица тарифов (назовем ее TT). Какова ее структура ? Что там, виды услуг, тарифы с изменением по периодам времени ? Как из нее выбираются записи ? Тарифы выбираются в основном цикле по абонентам ? Имеется таблица оплат (назовем ее TO aka PLATA2011). Она хранит в одной записи все оплаты абонента за 10 лет по месяцам ? Или за 1 год ? Что такое 30 ? В приведенной процедуре просто сбрасывается какая-то одна запись. Зачем выполняется магическое действие сначала считывания из таблицы в массив, а затем запись из массива в таблицу каких-то данных ? Это одни и те же данные ? Зачем их гонять туда-сюда ? Что и как хранится отдельно по каждому подьезду и заносится в, хм, БД, Договора ? Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд. Андрей, моих способностей гадалки, телепата и экстрасенса недостаточно. Если хочешь какой-то помощи - подробно опиши свой алгоритм, со всеми выполняемыми действиями. Ну а нет - так нет.
Пару слов про использование массива. 1. В цикле можно использовать промежуточную переменную:
amj := aMassiv[nJ]
и затем вместо aMassiv[nJ,A_TARIF] использовать amj[A_TARIF], и так для всех 12-ти элементов
2. Поскольку для расчета всех абонентов используется массив одинакового размера, его можно не создавать/уничтожать для каждого абонента, а использовать один и тот же, просто перекрывая данные. Это позволит избежать несколько десятков тысяч операций создания/уничтожения.
Впрочем, думается, это даст немного. Узкое место еще ведь не выяснено. Хотя, конечно, можно использовать чудесный "метод подитогов" из 1С. Это сразу волшебным образом сократит время всего расчета до 1-й секунды.
Отправлено: 06.12.11 00:08. Заголовок: Pasha пишет: Я уже ..
Pasha пишет:
цитата:
Я уже устал напрягать свои и без того неразвитые телепатические способности :)
Ну извини, не хотел сильно нагружать !
Pasha пишет:
цитата:
Имеется таблица оплат (назовем ее TO aka PLATA2011). Она хранит в одной записи все оплаты абонента за 10 лет по месяцам ? Или за 1 год ? Что такое 30 ? В приведенной процедуре просто сбрасывается какая-то одна запись.
Одна запись хранит приходы денег, даты прихода денег, даты начисления и сумму начисления и т.д. за ОДИН год. 30 записей за год (т.к. я писал ранее про "ерунду" творящуюся при перечислении денег) и 12 записей не хватает на год.
Pasha пишет:
цитата:
Зачем выполняется магическое действие сначала считывания из таблицы в массив, а затем запись из массива в таблицу каких-то данных ? Это одни и те же данные ? Зачем их гонять туда-сюда ?
Данные по абоненту, у которого различается тариф оплаты, сумма оплаты, сумма и дата прихода денег и т.д. - все загоняется в массив, далее делаем начисления (пересчет с начала года, мало ли что было: изменили тариф, ставки тех.обсл.), далее записываем массив в поля ОДНОЙ записи таблицы.
Pasha пишет:
цитата:
Что и как хранится отдельно по каждому подьезду и заносится в, хм, БД, Договора ?
Это пока несущественно.
Pasha пишет:
цитата:
Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд.
Хочу всю таблицу ТА записать в память, потом сделать начисления, а потом сбросить в таблицу ТА уже с расчетами на диск.
Pasha пишет:
цитата:
Андрей, моих способностей гадалки, телепата и экстрасенса недостаточно. Если хочешь какой-то помощи - подробно опиши свой алгоритм, со всеми выполняемыми действиями.
Понятно, что трудно понять чужую тематику (я сам уже в этот алгоритм 5 лет не лез, как с Клипера перенес) и с такими моими "куцими" объяснениями. Но я хотел не углубляться в код и не грузить вас этим. Придется наверно все-таки подробно ВСЕ описать. Но на это нужно время. Пока беру паузу для подготовки описания алгоритма. Чуть позже напишу. Спасибо за помощь !!!
Хочу всю таблицу ТА записать в память, потом сделать начисления, а потом сбросить в таблицу ТА уже с расчетами на диск.
Совершенно бессмыссленное намерение, которое только замедлит расчет. Когда записывать данные: в процессе расчета по одному абоненту, или в конце по всем - разницы не имеет. Более того, записывать по одному будет быстрее, так как запись уже спозиционирована, а если записывать все - эту запись надо еще найти. Да и к тому же держать в памяти сотни мегабайт или более данных на пользу не пойдет в любом случае.
Отправлено: 06.12.11 12:05. Заголовок: Андрей, не знаю тонк..
Андрей, не знаю тонкостей твоего алгоритма, но:
Pasha пишет:
цитата:
записывать по одному будет быстрее
В моей программе по расчету зарплаты пункта "Расчет" нет в принципе. При вводе бухгалтером любого начисления автоматически выполняется полный перерасчет по человеку. О плюсах и минусах такого подхода можно, конечно, спорить. Но могу сказать, что расчет выполняется мгновенно, БД всегда в актуальном состоянии. В твоем случае, когда перерасчет по человеку выполняется за 0.08 с, все это будет происходить незаметно даже без изменения существующего механизма обработки.
Отправлено: 06.12.11 12:16. Заголовок: Насколько я понимаю,..
Насколько я понимаю, здесь несколько другая специфика. Данные для начислений есть изначально, а вводятся только немногочисленные изменения. Так что без общего расчета не обойтись.
Отправлено: 06.12.11 13:08. Заголовок: Pasha пишет: без об..
Pasha пишет:
цитата:
без общего расчета не обойтись
Расчета чего? Суммы к оплате? А зачем ее хранить? Насколько я понимаю тариф - это условно постоянная величина, которую нет смысла дублировать (12 мес.) * (кол-во лет) * (кол-во абонентов) раз. Речь может идти только о хранении информации об оплате и льготах (если есть). Тогда при выводе информации (на принтер или монитор) о текущем состоянии расчетов с абонентом сумму к оплате можно получать динамически.
Если есть необходимость эту информацию разносить по другим таблицам, то это можно делать во время печати квитанций на оплату. "Тормозов" в расчете не будет, поскольку печать более медленная операция.
И о структуре таблицы оплат. Андрей, а что будет, если абонент будет вносить оплату не одной, а 2-3-... суммами ежемесячно? Не проще ли хранить информацию в виде ID абона, дата оплаты, сумма, за какой период, прочая сопроводительная инфа.
Хотя, опять же, не зная постановки задачи, трудно рассуждать.
Отправлено: 06.12.11 15:27. Заголовок: S-A-N пишет: И о ст..
S-A-N пишет:
цитата:
И о структуре таблицы оплат. Андрей, а что будет, если абонент будет вносить оплату не одной, а 2-3-... суммами ежемесячно? Не проще ли хранить информацию в виде ID абона, дата оплаты, сумма, за какой период, прочая сопроводительная инфа.
Вот из-за этого и сделано 30 граф для прихода денег PLATA2011 (почитай выше). А информация так и храниться в отдельной базе прихода денег (таблица оплат) по записям: 1запись - 1 приход денег.
Когда деньги за текущий месяц закончили приходить из банка, РКЦ и т.д. то делаем перенос денег по конкретным абонентам (в таблицу PLATA2011 в свободную ячейку), а потом уж делаем расчет (начисление) по всей таблице абонентов (ТА). Из-за этого раз в месяц нужно делать ОБЩИЙ расчет. После этого и делается печать долгов, печать квитанций и т.д., следуя специфики предприятия. Они все делают по разному, одни печатают, другие не печатают... их трудно понять....
Я на этой задаче 12 год сижу. Делал на Клипере 5.3 под Новел, потом перевел на хХарбор. Сейчас бы конечно сделал бы по другому, но тогда компы были очень слабыми, а Клипер шустро считал и выдавал сведения. А пределать что-то по другому в работающей программе - это целая ЭПОПЕЯ, всем сразу становится неудобно, шумят, что раньше понятней было и цвет лучше был и т.д. Одна морока по переводу.... Это если с нуля новому предприятию даешь новую программу, то все нормально, привыкают сразу.
Отправлено: 06.12.11 15:38. Заголовок: Andrey пишет: А инф..
Andrey пишет:
цитата:
А информация так и храниться в отдельной базе прихода денег (таблица оплат) по записям: 1запись - 1 приход денег.
Когда деньги за текущий месяц закончили приходить из банка, РКЦ и т.д. то делаем перенос денег по конкретным абонентам (в таблицу PLATA2011 в свободную ячейку), а потом уж делаем расчет (начисление) по всей таблице абонентов (ТА). Из-за этого раз в месяц нужно делать ОБЩИЙ расчет.
А зачем что-то куда-то переносить ? В таблице оплат достаточно иметь индекс по ID абонента и дате оплаты: Str(ID)+DTOS(Date), и по нему всегда можно выбрать оплату за произвольный промежуток времени. Если бы использовался letodb, это можно было бы сделать одним вызовом leto_Sum()
Отправлено: 14.12.11 03:19. Заголовок: Pasha пишет: Для че..
Pasha пишет:
цитата:
Для чего ты собрался использовать hbmemio ? Вместо массива 12*30, что ли ? Так это же полный абсурд.
Ну я ему посоветовал.. Но в тот момент я не знал, что и как Андрей собирается делать. И теперь не совсем понимаю логику его действий. А код WritDimDbf вообще вызывает улыбку
Отправлено: 14.12.11 11:18. Заголовок: Pasha пишет: Да, су..
Pasha пишет:
цитата:
Да, судя по всему, причина медленного расчета - неправильная организация данных Такое лечится только банальной нормализацией, и больше ничем.
А я разве спорю ? Это делалось еще в 1998 году, я про это писал уже....
Andrey пишет:
цитата:
Я на этой задаче 12 год сижу. Делал на Клипере 5.3 под Новел, потом перевел на хХарбор. Сейчас бы конечно сделал бы по другому, но тогда компы были очень слабыми, а Клипер шустро считал и выдавал сведения.
Петр пишет:
цитата:
А код WritDimDbf вообще вызывает улыбку
Ну извини, я тогда так сделал как понимал.... Заместо улыбок, лучше напиши как нужно делать правильно.
Все даты в формате GMT
3 час. Хитов сегодня: 147
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
- участник сейчас на форуме
- участник вне форума