Люди, вы здесь ваще бываете?

Форум » Clipper » Люди, вы здесь ваще бываете? » Ответить

Люди, вы здесь ваще бываете?

dr_yanson: Видимо, хана клипперу. Ссылки на сайте битые, или буржуйские. Ничего не найти по SIX3: -что это такое, где взять, и стОит ли брать? Искал фак по xHarbo-ру - нигде! Спрашивал про модем тут, на форуме. Я, чтоли, тут первый такой шизанутый с такими вопросами? Люди - хелп!

Ответов - 56, стр: 1 2 3 All

Сергей Р: А что , поиск уже нас не устраивает ? six3 - http://clipper.borda.ru/?1-0-0-00000320-000-0-0-1158335642 документация по xHarbour http://clipper.borda.ru/?1-4-0-00000126-000-10001-0-1166565472 и т.д.

suv3: Сергей Р пишет: Видимо, хана клипперу Понимаешь.... Если бы он работал - ему бы хана не настала. Потому что у тех же буржуев до сих пор программы на Коболе и Фортране. И на коболе с фортраном до сих пор пишут. И есть вакансии. Беда клиппера в том, что он ни хрена не работает. Нет ни одного рабочего драйвера БД, сикс - не исключение. Есть более-менее работоспособный АДС, но область его применения весьма ограничена - это Netware со всеми вытекающими. Да и глюков в АДС тоже хватает

Dima: suv3 Юра а ты счас сам то на чем пишешь ? ;)

suv3: Да не пишу я.... Пустое это всё) программист - затычка и мальчик на побегушках до пенсии Менеджмент - вот это профессия.

Dima: suv3 пишет: программист - затычка и мальчик на побегушках до пенсии ясно , усвоил ;)

Andrey: suv3 пишет: Да не пишу я.... Пустое это всё) программист - затычка и мальчик на побегушках до пенсии Менеджмент - вот это профессия. Каждому своё . Кому нравиться молоко, а кому молочница.

p519446: SUV пишет: Беда клиппера в том, что он ни хрена не работает. Нет ни одного рабочего драйвера БД, сикс - не исключение. Есть более-менее работоспособный АДС, но область его применения весьма ограничена - это Netware со всеми вытекающими. Да и глюков в АДС тоже хватает Не согласен (по поводу АДС): 1) под виндузой он тоже работает; есс-сно, будет медленнее, чем под новеллом, но виндуза сама по себе - система не для сервера, а для усеров. Даже с надписью "Windows 2003 SuperPuper-Pro Postfix 1762 Final Release 1542". Горбатую систему только могила исправит. 2) какие "вытекающие" из того, что на сервер надо ставить Новелл ? Это операционка, не требующая вмешательства по многу месяцев. Даже при отвратительной сетке и ленивых админах. Тесты, проводившиеся Extended Systems, показывают, что скорость обработки файлов на новелле в 1.5 (кажись) раза выше, чем на виндузе. 3) глюки в АДСе есть. И вылезают они практически всегда из-за поганой работы сети. Но, как оказалось, их можно "душить", если пытаться делать все операции открытия/создания файлов (.dbf, .cdx) в ЦИКЛЕ

p519446: ... сорри, не дописал предыдущий пост (случайно пнул "Отправить"). Так вот: АДС часто капризничает при попытке открыть или создать файл. Наиболее распространённая ошибка -- 6313. Однако она весьма часто "гасится", если её перехватывать, протоколировать куда-нить и ПОВТОРЯТЬ неудавшуюся операцию в цикле. Я посмотрел протоколы таких чисто АДС-ных ошибок у себя в конторе: очень часто после 5-7 попытки работа нормально продолжалась. 4) при переводе приложения на работу под транзакциями ДОСТОВЕРНОСТЬ (непротиворечивость) данных становится, имхо, 99.9%. Если, конечно, нет ошибок в самих алгоритмах. Одну десятую процента оставляем на случай заливки сервера кипятком или падения со стола. Отключения усеровских компов, аварии в электросети - всё становится похрену. Вывод (2 dr_yanson): надо искать не SIx, а ADS. При числе усеров > 50 - точно не пожалеешь. ЗЫ. Между прочим, как ни странно, в случае аварии на серваке виндуза поведёт себя лучше нетвари. Потому что нетварь очень сильно использует память для кеширования и сбрасывает на диск новые данные ДАЛЕКО не сразу. У меня был случай, когда в справочник завели новую строку (в 9:30 утра), в 17:00 сервер NetWare "завис" и после рестарта этой строки в справочнике не оказалось (к счастью, все данные были на бэкапе). Впрочем, это уже другая тема.

lista: suv3 пишет: Беда клиппера в том, что он ни хрена не работает. Нет ни одного рабочего драйвера БД, сикс - не исключение. Есть более-менее работоспособный АДС, но область его применения весьма ограничена - это Netware со всеми вытекающими. Да и глюков в АДС тоже хватает Беда в головах... А по-поводу "надежности". Хотелось бы отдельно прояснить. У многих программистов и пользователей существует предвзятое мнение, что DBF - это очень ненадежно, что системы, построенные на xBase, подвержены разрушениям данных и индексов. Извините, но это совсем не так. DBF тут совсем ни при чем. Разрушения происходят по вине технологии файл-сервер, в которой надежность всей системы зависит от каждой единицы "железа", используемого в обработке данных. Если же использовать технологию терминал-сервер (например, в связке Linux+DosEmu, Linux-Clip), то разрушения данных просто не возникают, так как вся обработка данных производится на сервере и никак не зависит от пропаданий 220В на клиентских станциях.

Dima: p519446 пишет: Потому что нетварь очень сильно использует память для кеширования и сбрасывает на диск новые данные ДАЛЕКО не сразу Кто мешает "тонко" настроить кэш в Netware ? ;)

p519446: Dima пишет: Кто мешает "тонко" настроить кэш в Netware ? ;) Пробовали. Тормоза начинаются, и весьма заметные (у нас число АКТИВНЫХ усеров тогда было больше 120). Да и зачем его перестраивать, этот кеш, в сторону уменьшения времени хранения без записи на диск ? Если есть регулярный бэкап (каждые 15 минут), то потери данных при взрыве сервака составят макс 15 минут. Для нас, по кр. мере, это не смертельно.

Григорьев Владимир: 1. В отношении ADS. Конечно эта система более надежная по сравнению с обычными драйверами Clipper, однако ее завышенная цена делает эту систему недоступной для большинства Clipper-программистов. Так что ADS не является панацеей от возникающих проблем при работе с базами данных. 2. Мнение к DBF не предвзятое, а реальное. У DBF-системы нет понятия транзакции, поэтому использование их в многопользовательской системе делает их ненадежными.

Dima: Григорьев Владимир пишет: однако ее завышенная цена делает эту систему недоступной для большинства Clipper- Поднимите руку кто юзает ADS оффициально купленный ;)

lista: Григорьев Владимир пишет: 2. Мнение к DBF не предвзятое, а реальное. У DBF-системы нет понятия транзакции, поэтому использование их в многопользовательской системе делает их ненадежными. Я не пойму, чем не устраивает терминальная система работы?

Григорьев Владимир: lista пишет: Если же использовать технологию терминал-сервер (например, в связке Linux+DosEmu, Linux-Clip), Я так думаю, что прикладной программист, коим является программист по Clipper, не должен заниматься связками Linux+DosEmu или какими-то другими. Он разрабатывает приложения для той платформы, которая имеется у заказчика. Я думаю, никто не будет спорить, что подавляющее большинство заказчиков имеют различные системы Windows, а не связки Linux+DosEmu.

Григорьев Владимир: Dima пишет: Поднимите руку кто юзает ADS оффициально купленный ;) Вот это-то как раз и плохо!

lista: Да как сказать! Одно дело программировать на не надежной платформе и ломать голову по вопросам развала индексов, скорости... и жаловаться и плакать на это. Или поставить заказчику ОДИН Linux+Clip на сервер, а рабочие машины Telnet. И забудете про проблемы скорости, развала индексов... Пишите в свое удовольствие.

Григорьев Владимир: lista пишет: Или поставить заказчику ОДИН Linux+Clip на сервер, а рабочие машины Telnet. По сути дела это означает сменить специализацию с программиста на системного администратора!

p519446: Григорьев Владимир пишет: У DBF-системы нет понятия транзакции, поэтому использование их в многопользовательской системе делает их ненадежными Зато у АДС оно есть. В том числе и для использования в .dbf. После того, как я перевёл свою систему на работу с транзакциями, ушёл в прошлое весь этот гимор с "непонятными" результатами в виде "частично" записанных документов, "странными" остатками на складе или на балансах клиентов и т.п. Dima пишет: Поднимите руку кто юзает ADS оффициально купленный ;) Требую прекратить издевательство над здравым смыслом! :-))

lista: А кто вам Винду ставит на машины? Да если нет СисАдмина..., то да прийдется самому настроить Линух. Да и не большая там "заморочка" установка Линуха и Клипа. Но даже если это освоить оно окупится... и это намного дешевле, чем юзать Новелы или АДС, которые все равно не дадут надежности терминальных систем.

Григорьев Владимир: lista пишет: Да и не большая там "заморочка" установка Линуха Это как сказать! Одних только Линусов существует несколько дистрибутивов! А что делать с Windows? Забыть?! Нельзя объять необъятное! (Козьма Прутков)

lista: Да все равно какой дистрибутив Линуха, можно и ФриБсд Настройки теже, что и в Винде: - сетка - принтера - приложения - пользователи Винду - рабочая платная станция, которая валится, зависает, индексы рушатся..., т.е. требует обслуживания, восстановления БД вот куда нужно голову приложить.

p519446: lista пишет: это намного дешевле, чем юзать Новелы или АДС, которые все равно не дадут надежности терминальных систем. 1) простите, а мы в ГДЕ живём, чтобы беспокоиться о ценах на новелл/виндузу/АДС ? Или Вы под понятием "дешевле" понимаете объём трудозатрат на администрирование новелла ? (АДС вообще не требует админнистрирования) 2) без транзакций - да, не дадут. С транзакциями - не вижу причины, чем терминальная система надёжнее. Потому что если Ваш сервер рухнет посередине рабочего дня, эффект будет одинаковым% работал он на новелл+АДС или это был терминальный сервер.

p519446: p519446 пишет: Винду - рабочая платная станция, которая валится, зависает, индексы рушатся..., т.е. требует обслуживания, восстановления БД вот куда нужно голову приложить. И кто должен голову приложить к этой винде ? Программист-клипперщик, что ли ?!

suv3: p519446 пишет: Не согласен (по поводу АДС): не важно, что правда, а что нет... главное, чтобы ты сам в это верил) зы. мыло на яндексе игноришь?

lista: p519446 пишет: 2) без транзакций - да, не дадут. С транзакциями - не вижу причины, чем терминальная система надёжнее. Потому что если Ваш сервер рухнет посередине рабочего дня, эффект будет одинаковым% работал он на новелл+АДС или это был терминальный сервер. С такой постановкой задачи и "сервер с транзакциями" не поможет, если он же рухнет "посередине рабочего". Да и затраты для перехода на сервер с транзакциями какие? А что Вы хотите: - повысить нажежность - повысить скорость - остатся на Клиппере Есть опыт запуска и на сетке до 10 машин и сетке из полсотни машин. Здесь запускали систему в начале на Целероне 2,0GHz и RAM 2Гб. Сейчас побольше машина, т.к. нужно делать выборки.

lista: p519446 пишет: И кто должен голову приложить к этой винде ? Программист-клипперщик, что ли ?! Так здесь эти вопросы довольно таки часто обсуждаюстя. - что и как RegEdit подправить - что в Новеле настроить - протокол какой постаить, какой удалить - ...

p519446: Ну хорошо, а к надёжности клипперных программ это как относится ? (я к тому, что топик этот "развился" благодаря фразе SUV'a, что на клиппере нельзя сбацать работающую прогу)

Dima: p519446 пишет: (я к тому, что топик этот "развился" благодаря фразе SUV'a, что на клиппере нельзя сбацать работающую прогу) я с Юрчиком не согласен , можно сбацать ;)

p519446: lista пишет: Да и затраты для перехода на сервер с транзакциями какие? А что Вы хотите: - повысить нажежность - повысить скорость - остатся на Клиппере 1) затраты не маленькие, не спорю; 2) с клиппера, ес-сно, соскочить уже давно хочется. Но для этого надо, чтобы работающая система, обслуживающая свыше 100 человек, работала... надёжно и быстро :-) Потому что иначе заниматься разработкой новой системы просто не дадут.

lista: p519446 пишет: 1) затраты не маленькие, не спорю; 2) с клиппера, ес-сно, соскочить уже давно хочется. Но для этого надо, чтобы работающая система, обслуживающая свыше 100 человек, работала... надёжно и быстро :-) Потому что иначе заниматься разработкой новой системы просто не дадут. У Вас, что сейчас на файл-серверной технологии работает 100 чел? И как? Я видел, какая это работа на при 40-50 челах и Новел сервером. Удручающе. После перехода на Линух+Клип, больше не хотят возврата. Для терминальной системы разрабатывать ничего не нужно! Сменил платформу и всЕ, т.е. назад к прошлому (МайФреймы).

lista: p519446 пишет: Ну хорошо, а к надёжности клипперных программ это как относится ? (я к тому, что топик этот "развился" благодаря фразе SUV'a, что на клиппере нельзя сбацать работающую прогу) Да на прямую. Когда писали задачи к Клиппере для одной машины - все было чудно. Начались сети. Пока 3-5 машини сносно и то..., а когда 20-30 вот здесь и началось, что Клиппер ни куда не годится. Хотя для локальной машины задача работала на Ура. Так проблемы не в Клиппере, в кривости платформы (железа) на которой эта задача запущена. Клиппер здесь не причем.

Dima: p519446 пишет: Так вот: АДС часто капризничает при попытке открыть или создать файл. Наиболее распространённая ошибка -- 6313. Однако она весьма часто "гасится", если её перехватывать, протоколировать куда-нить и ПОВТОРЯТЬ неудавшуюся операцию в цикле. Я посмотрел протоколы таких чисто АДС-ных ошибок у себя в конторе: очень часто после 5-7 попытки работа нормально продолжалась. Ни разу не замечал такого , все нормально открывается с первого раза. Везде где ставлю прогу с поддержкой ADS , везде только Netware сервак. Открытие баз в цикле это ты сильно замутил ;) Готов обсудить вопрос , если интерестно. Ты либо что то не то линкуешь или же что то чисто ADSовое не отрубил в самой программе. 6313 как правило бывает если не верно протоколы настроены или же сетевых карт в тачке больше одной ;) на ровном месте она практически не возникает. По ходу нужно еще и файервол правильно настроить если таковой установлен на рабочей станции , при чем к каждому Firewall свой подход.

p519446: lista пишет: Начались сети. Пока 3-5 машини сносно и то..., а когда 20-30 вот здесь и началось, что Клиппер ни куда не годится. Хотя для локальной машины задача работала на Ура. Пресловутый предел "20-30 машин" вы достигли как раз из-за свойств клиппера. Потому что без SIX'a он именно на этом кол-ве усеров начинает валиться (чаще всего падают индексы, затем - повреждаются заголовки .dbt). Даже при идеальной сетке абсолютно безошибочно написанная клипперная прога будет необъяснимым образом периодически падать. При использовании SIXa дело обстоит лучше, "предел усеров" отодвигается до 40-60. Но дальше опять. Прибавьте сюда то, что усеры ВСЕГДА будут завершать работу вашей проги некорректно (скажем, закрывать "крестиком" или вообще тушить комп кнопкой). Также учитывайте и то, что 220В в любой момент могут пропасть. Усеров лечить бесполезно. Электриков тоже. И на самом хорошем железе такая данные вашей проги всё равно будут рано или поздно "криветь". А причина тут простая: нельзя делать обработку на клиенте. Ненадёжно всё это слишком.

p519446: 2Dima: увы, когда я переделывал прогу под АДС, то даже предположить не мог, что он такой капризный окажется (по кр. мере, на нашей сетке с сегментами длиной гораздо больше максимально допускаемых стандартом ethernet 100 м). Даже когда я его тестировал перед вводом на 70 машинах - ничего не было. Тест был максимально приближенным к "боевым условиям": на 60 тачках шла эмуляция "неторопливого ввода" данных усерами, а на 10 - составление "тяжелых отчетов" бухгалтерией. Конечно, сервак на таком тесте был загружен почти до 90%, но сам АДС никаких отказов не выдавал. Правда, в тесте не было интенсивного создания временных файлов, а в самой проге они создаются/юзаются/закрываются/удаляются весьма интенсивно. А вот когда началась реальная эксплуатация, то все эти 6313 полезли как тараканы. И выскакивали они самым непредсказуемым образом. Были и другие ошибки, но они, в основном, возникали из-за старых версий новелловского клиента. Я его сразу поменял на 4.91SP2 и это решило почти все пролблемы. Кроме 6313 (которая в 90% сопровождается выводом сообщения "DOS error 250"). Рытьё в ADS Knowledge Base и ADS newsgroup мало что дало, кроме одного: я нашёл параметр, которые по умолчанию НЕ указывается в ADS.CFG, потому что, дескать, он нужен "очень редко". Этот параметр называется PARTIAL_CONNECTION_TIMEOUT и смысл его в том, что когда рабочая станция не отвечает серваку в течение нек-рого времени, то он её обрубает. С выводом как раз этой 6313 + DOS error 250. Так вот: по умолчанию этот параметр равен 2 минуты. Я его увеличил и кол-во 6313 уменьшилось. Но НЕ до нуля, к сожалению. Сейчас я практически на 100% уверен, что всё дело в сети. Причём, протоколы говорят однозначно: ошибка эта лезет ТОЛЬКО по будням и ТОЛЬКО при большом кол-ве усеров (больше 80). Сетевые карты у нас везде по 1 штуке (на раб станциях). Протоколы везде также настроены правильно (это было сделано 1 раз и дальше образ виндузы был залит на болванку; дальше все раб станции делаются с этой "эталонной" болванки"). Файрволов на рабочих станциях у нас нет. ЗЫ. Вот что гласит дока на тему PARTIAL_CONNECTION_TIMEOUT: ; This setting tells the server how long (in milliseconds) to wait for a client ; to fully connect. ; If the client does not fully connected within this time, the server will ; disconnect the partial connection. This setting should only need to be ; increased in very rare conditions where a slow network is causing connection ; failures. In this case, this setting should be used in conjunction with the ; Advantage client setting of Max Timeouts. ; The Max Timeouts setting is the amount of time the client waits ; ; for a response from the Advantage Database Server. ; Add the following line in the Advantage Database Server configuration file ; (ADS.CFG): ; Default is 120000 (2 minutes). ; Minimum value is 10000 (10 seconds). ; ADDED 2006-11-09 22:07 (ZOTOV): PARTIAL_CONNECTION_TIMEOUT=480000

Dima: p519446 Сдаюсь ;) У меня максимум клиентов в сетке под ADS больше 30 пока не превышало. Спасибо за науку , буду знать на будущее что такое может быть , я про 6313 и в этом духе.

Dima: Кстати вопрос ко всем !!! Чем и как корректно скопировать этот форум для локального просмотра ??? Юзал ряд прог но результат фиговый............... Хотелось бы слить форум на диск и локально спокойно читануть без захода в инет.

p519446: Dima пишет: У меня максимум клиентов в сетке под ADS больше 30 пока не превышало. Имхо, АДС выдаёт 6313 не из-за одного лишь большого кол-ва клиентов. Сетка у нас поганая просто. И именно сочетание "поганая сетка" + "большое кол-во активных усеров" = 6313. Более того, я неоднократно замечал: эта ошибка может вылезти ВЕРОЯТНЕЕ ВСЕГО на тех машинах, которые в данный момент... простаивают. Вернее, у меня они не простаивают, а с интервалом примерно 20-30 сек делают поиск т.н. "стоп-файла" (чтобы мне никого не обзванивать с просьбой о выходе) и, кроме того, некоторые тачки также кое-что делают даже при простое (выполняют регулярный поиск в БД некоторых спецпризнаков). Так вот: чаще всего валятся именно эти, "ничего" не делающие тачки. Почему - х/з.

Dima: p519446 пишет: Так вот: чаще всего валятся именно эти, "ничего" не делающие тачки. Офигеть , я не знал............. В дальнейшем думаю очень пригодится , спасибо !!!!!!!!!!!!!!!!

Сергей Р: Dima пишет: Чем и как корректно скопировать этот форум для локального просмотра ??? Например Offline Explorer

Сергей Р: А вообще-то универсальной программы наверно нет , движки форумов больно уж разные .

Сергей Р: Можно попробывать http://www.httrack.com/ или Teleport ( но не всегда удачно )

lista: p519446 пишет: использовании SIXa дело обстоит лучше, "предел усеров" отодвигается до 40-60. Но дальше опять. Прибавьте сюда то, что усеры ВСЕГДА будут завершать работу вашей проги некорректно (скажем, закрывать "крестиком" или вообще тушить комп кнопкой). Также учитывайте и то, что 220В в любой момент могут пропасть. Усеров лечить бесполезно. Электриков тоже. И на самом хорошем железе такая данные вашей проги всё равно будут рано или поздно "криветь". А причина тут простая: нельзя делать обработку на клиенте. Ненадёжно всё это слишком. А я про, что говорю!!! Вот эти, то проблемы и лечит терминальная система работы. Возмите по-пробуйте. Что мешает?

p519446: Мне уже поздно что-то пробовать - слишком большая прога, слишком много усеров. Даже если в процессе тестирования не найду ни одной ошибки или трабла, это СОВЕРШЕННО не говорит о том, что когда будет реальная эксплуатация и все 120 усеров на неё навалятся, то также всё будет Ок. Скорее, наоборот. Потому что когда я тестировал SIX и затем, через год, АДС - тоже всё было гладко и спокойно. А когда началась реальная экспл-ция, колбасило несколько месяцев (АДС). Есть еще один момент: терминальная система работы предполагает ПОЛНОЕ отключение клиентских машин из вычислительной деятельности. Т.е. вся нагрузка по арифметике и работе со строками ляжет на хрупкие плечи сервера. А у меня в проге достаточно и арифметики и, особенно, операций со строками. Какие требования надо в таком случае предъявлять к серверу, чтобы усеры не видели задержек ? Какая у него должна быть память, диски, ЦПУ ? Имхо, совсем не такие как сейчас (будете смеяться, но до сих пор фурычит P-III/700/512; из общего объёма RAM только около 20Мб жрёт АДС). ЗЫ. У нас в конторе есть терминальная прога (не на клиппере), на ней сидит около 60 человек. По недавнему признанию её автора, работа часто тормозится, особенно по утрам (в "часы пик"). Хотя сервак там нормальный, вроде бы.

p519446: 2lista. И еще. Предположим, что в Вашей проге в результате некоторой АЛГОРИТМЕЧЕСКОЙ ошибки в БД в некоторых случаях могут попадать некорректные с т.зр. бизнес-логики данные. Например, отрицательные остатки по к-л позициям склада и т.п. Без использования транзакций Вы не сможете предотвратить появление таких данных и будете периодически руками их выкорчёвывать. Потому что понятия "откат изменений" в клипперной системе (даже самой терминальной на свете) - нет. И второй вопрос. Даже если у Вас абсолютно выверенная (в смысле отсутствия ошибок в алгоритмах) система, всё равно остаётся "человечий фактор". А именно: какому-нибудь усеру рано или поздно обязательно "покажется", что программа зависла. Хотя она работает, пишет данные (но данных этих много и при хорошей загрузке сервера обновления, отклик системы на экране и т.п. - идут не всегда с достаточной скоростью). По своему опыту знаю, что задержка в отклике свыше 3 секунд БУДЕТ провоцировать усера шлёпнуть по к-л клавише. И в конечном счете, обязательно случится, что какой-нить удод закроет Ваше приложение некорректным образом (снимет терминальную задачу). Если в этот момент прога выполняет ОДНУ операцию - тут всё Ок, сервер её должен сам "доделать". А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ?

Григорьев Владимир: p519446 пишет: А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ? Может быть для товарных накладных написать свою эмуляцию транзакции? То есть сначала все данные записываются в какой-то временный файл. Затем по закрытию накладной или нажатию клаиши, что-то вроде "сохранить", данные из временного файла переписываются в основную базу данных. Тогда если программа "вылетела", то на диске сохраняется временный файл, и по этому событию можно судить, что транзакиця не выполнилась. И следовательно из базы данных нужно удалить те записи, которые уже успели туда попасть, а всю транзакцию пересохранить в базе данных заново.

p519446: Григорьев Владимир пишет: И следовательно из базы данных нужно удалить те записи, которые уже успели туда попасть, а всю транзакцию пересохранить в базе данных заново. Я знаю этот метод. И читал в Инете, что им пользуются (где-то в "историях успеха", перечисленных для АДСа на сайте их русского дистрибьютера - hotsoft.ru). Однако: 1) трудозатраты на переделку приложения будут при этом ТАКИМИ же, как если сразу переделывать под работу настоящих АДС-транзакций. Именно так ведь и происходит у меня: сначала запрашиваются ресурсы (добавляются строки, ставятся блокировки), затем объявляется BEGIN TRAN и строки, которые предназначены для записи, заполняются данными. В завершении -- COMMIT. Различие только в том, что я не пишу во времянки; всё - сразу в живые файлы. 2) всё равно надо написать "единую точку" входа данных в БД, в которой проверять соответствие данных времянки бизнес-правилам. И не только данных времянки! Ведь эти данные будут чатсо СКЛАДЫВАТЬСЯ с данными основных файлов (например, с остатками склада). След., проверять надо еще и БУДУЩИЙ РЕЗУЛЬТАТ, который возникнет в основных файлах. 3) время проверки для большого числа строк может составить 2-3 секунды. А может, и больше. Это достаточно, чтобы когда-нибудь "поймать" гадость типа сбоя 220В или (что у нас гораздо чаще бывает) зависания машины/сети/хаба. Потому что закон Мерфи никто не отменял: всё что только может произойти, произойдёт ОБЯЗАТЕЛЬНО, причём в самом худшем проявлении. И я на этот закон налетал десятки раз. 4) даже если сами данные нормальные, алгоритм ПРОВЕРКИ может сбойнуть, т.к. сам запросто может содержать к-л ошибку или неверное предположение. Потому что его тоже пишет живой проггер, а не автомат. В результате пп 3 и 4 - чистка БД руками. Иногда - с отрубанием усеров минут на 20 (а это плохо). Именно эти факторы меня окончательно "достали" и заставили всё переделать под TRN. О чём нисколько не жалею теперь.

lista: p519446 пишет: И второй вопрос. Даже если у Вас абсолютно выверенная (в смысле отсутствия ошибок в алгоритмах) система, всё равно остаётся "человечий фактор". А именно: какому-нибудь усеру рано или поздно обязательно "покажется", что программа зависла. Хотя она работает, пишет данные (но данных этих много и при хорошей загрузке сервера обновления, отклик системы на экране и т.п. - идут не всегда с достаточной скоростью). По своему опыту знаю, что задержка в отклике свыше 3 секунд БУДЕТ провоцировать усера шлёпнуть по к-л клавише. И в конечном счете, обязательно случится, что какой-нить удод закроет Ваше приложение некорректным образом (снимет терминальную задачу). Если в этот момент прога выполняет ОДНУ операцию - тут всё Ок, сервер её должен сам "доделать". А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ? Я в свое время тоже задавал такой вопрос. Как мне объяснили процесс (задача) будет работать до тех пор пока не встретит на своем пути inkey() (на inkey()-реализован весь ввод с клавы), запрос на ввод данных с терминала. И если этого терминала на другом конце уже нет (закрыли крестом, пропало 220, выдернули кабель...) то, тогда программа вывалится с ошибкой. На 50 юзерах я не видел перекособоченных документов (шапка есть, строк нет или частично нет). Реальный опыт больше 2-х лет.

lista: p519446 пишет: Мне уже поздно что-то пробовать - слишком большая прога, слишком много усеров. Даже если в процессе тестирования не найду ни одной ошибки или трабла, это СОВЕРШЕННО не говорит о том, что когда будет реальная эксплуатация и все Ничего не позно. Куда я пришел было наверное тоже самое. Хотел задачу запусить под ДОСЭМУ самое простое, но задача не собралась в Рела-моде. Только в Протек-моде, в это режиме под ДОСЭМУ не удалось решить проблему сжирания процессора. Пересобрали задачу на Clip. Первый сервер был Целерон 2гГц и памяти 1Гб тормозило только когда запускали большие отчеты. Но и то равномерно у всех. На терминалах по-запускал все, что можно даже машины под чистым ДОС-ом. Скорость была таже, что на новом системном блоке - терминалы же. p519446 пишет: Есть еще один момент: терминальная система работы предполагает ПОЛНОЕ отключение клиентских машин из вычислительной деятельности. Т.е. вся нагрузка по арифметике и работе со строками ляжет на хрупкие плечи сервера. А у меня в проге достаточно и арифметики и, особенно, операций со строками. Какие требования надо в таком случае предъявлять к серверу, чтобы усеры не видели задержек ? Какая у него должна быть память, диски, ЦПУ ? Имхо, совсем не такие как сейчас Я не знаю задачи. Но на юзера нужно порядка 4Мб памяти+система - да и памяти никогда не бывает много, диски - сам можешь прикинуть (брал сказевы физические зеркала). Реально юзеров разделили: - те кто набирает (здесь самое критичное) - и те кто выборки делает (да и задачи у них написаны на Фокпро и доспуп в только в режиме чтения) По ЦПУ взяли 2-х процессорную машину с гипертрейдами, т.е. Линух видет 4 проца. Система сама распределает потоки (задачи). Код почти не переделывали, был глюк с длинными транзакциями, т.е. запись держали долго. Переделали на короткую, все ОК. Уже перевели и три филиала на терминальную систему (была винда). А перейти просто, можно даже частями. Собралась бы задача под Clip-оп. Пробовать нужно. Хуже 100% не будет.

lista: p519446 пишет: Однако: 1) трудозатраты на переделку приложения будут при этом ТАКИМИ же, как если сразу переделывать под работу настоящих АДС-транзакций. Именно так ведь и происходит у меня: сначала запрашиваются ресурсы (добавляются строки, ставятся блокировки), затем объявляется BEGIN TRAN и строки, которые предназначены для записи, заполняются данными. В завершении -- COMMIT. Различие только в том, что я не пишу во времянки; всё - сразу в живые файлы. Во-во! Так только в Клиппер появились множественные блокировки, я так и делаю. - добавляю и блокирую - записываю - разблокировка Только все это запускал сразу под ДОСЭМУ и затем под Клип-ом. Проблем с этим нет работает!

p519446: lista пишет: Как мне объяснили процесс (задача) будет работать до тех пор пока не встретит на своем пути inkey() (на inkey()-реализован весь ввод с клавы), запрос на ввод данных с терминала. И если этого терминала на другом конце уже нет (закрыли крестом, пропало 220, выдернули кабель...) то, тогда программа вывалится с ошибкой. А теперь, внимание, вопрос: допустим, Вам надо обработать документ с 300 строками (скажем, применить к стоимостям скидку NN %). Вы его, если я правильно понял, сначала копируете во времянку, затем модифицируете её и далее - пишите из времянки в основной файл. Меня интересует именно последний этап: что будет, если при записи 300 строк (которая длится НЕ 0.00 сек, а немного больше) эту задачу "снять крестиком" ? Что сделает серверная ОС, на которой крутится всё это ? Доведёт до конца или нет ? Если нет, то что в результате будет с основным файлом, у него строки частично поменяются или всё откатится назад (как будто преобразований не было) ?

lista: p519446 пишет: что будет, если при записи 300 строк (которая длится НЕ 0.00 сек, а немного больше) эту задачу "снять крестиком" ? Что сделает серверная ОС, на которой крутится всё это ? Доведёт до конца или нет ? Если нет, то что в результате будет с основным файлом, у него строки частично поменяются или всё откатится назад (как будто преобразований не было) ? Если говорить о серверной оси Линух, операции обработки баз данных не требуют наличия "живого" терминала. Что от туда ждать программе? Т.е. программа доработает свои 300 строк, дойдет до inkey() и отвалится.

p519446: Ладно, тогда последний вопрос: если мне надо будет сделать такую связку у себя дома, то что, устанавливать Линух ? Или второй комп ставить ? (вопрос без иронии, просто интересуюсь)

Dima: p519446 пишет: Ладно, тогда последний вопрос: если мне надо будет сделать такую связку у себя дома, то что, устанавливать Линух ? Или второй комп ставить ? (вопрос без иронии, просто интересуюсь) Поставь например http://www.vmware.com/products/ws/

lista: p519446 пишет: Ладно, тогда последний вопрос: если мне надо будет сделать такую связку у себя дома, то что, устанавливать Линух ? Или второй комп ставить ? (вопрос без иронии, просто интересуюсь) - можно и вторую машину поставить с Линухом, больших ресурсов для портирования-разработки не нужно. - на своей же машине вторую ось поставить (как это сделать в Инете есть описалово) - wnware не пробовал - еще вариант - это Клип можно собрать запустить ч.з. Cygwin (но в боевой работе не пробовал)

p519446: Ладно, попробую как-нибудь. Но с транзакциями под АДСом мне как-то больше нравится. "Ближе к мировым стандартам", так сказать... :-)

полная версия страницы