Отправлено: 20.12.06 10:50. Заголовок: Люди, вы здесь ваще бываете?

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

 Отправлено: 20.12.06 11:22. Заголовок: Re:

А что , поиск уже нас не устраивает ?
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
и т.д.

 Отправлено: 20.12.06 12:35. Заголовок: Re:

Сергей Р пишет:

цитата:

Видимо, хана клипперу

Понимаешь.... Если бы он работал - ему бы хана не настала. Потому что у тех же буржуев до сих пор программы на Коболе и Фортране. И на коболе с фортраном до сих пор пишут. И есть вакансии.

Беда клиппера в том, что он ни хрена не работает. Нет ни одного рабочего драйвера БД, сикс - не исключение. Есть более-менее работоспособный АДС, но область его применения весьма ограничена - это Netware со всеми вытекающими. Да и глюков в АДС тоже хватает

 Отправлено: 20.12.06 12:39. Заголовок: Re:

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

 Отправлено: 20.12.06 12:50. Заголовок: Re:

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

Менеджмент - вот это профессия.

 Отправлено: 20.12.06 12:58. Заголовок: Re:

suv3 пишет:

цитата:

программист - затычка и мальчик на побегушках до пенсии

ясно , усвоил ;)

 Отправлено: 20.12.06 13:57. Заголовок: Re:

suv3 пишет:

цитата:

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

Каждому своё .
Кому нравиться молоко, а кому молочница.

 Отправлено: 22.12.06 03:18. Заголовок: Re:

SUV пишет:

цитата:

Беда клиппера в том, что он ни хрена не работает. Нет ни одного рабочего драйвера БД, сикс - не исключение. Есть более-менее работоспособный АДС, но область его применения весьма ограничена - это Netware со всеми вытекающими. Да и глюков в АДС тоже хватает

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

 Отправлено: 22.12.06 03:36. Заголовок: Re:

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

Вывод (2 dr_yanson): надо искать не SIx, а ADS. При числе усеров > 50 - точно не пожалеешь.

ЗЫ. Между прочим, как ни странно, в случае аварии на серваке виндуза поведёт себя лучше нетвари. Потому что нетварь очень сильно использует память для кеширования и сбрасывает на диск новые данные ДАЛЕКО не сразу. У меня был случай, когда в справочник завели новую строку (в 9:30 утра), в 17:00 сервер NetWare "завис" и после рестарта этой строки в справочнике не оказалось (к счастью, все данные были на бэкапе). Впрочем, это уже другая тема.

 Отправлено: 22.12.06 10:27. Заголовок: Re:

suv3 пишет:

цитата:

Беда клиппера в том, что он ни хрена не работает. Нет ни одного рабочего драйвера БД, сикс - не исключение. Есть более-менее работоспособный АДС, но область его применения весьма ограничена - это Netware со всеми вытекающими. Да и глюков в АДС тоже хватает

Беда в головах...

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

 Отправлено: 22.12.06 13:15. Заголовок: Re:

p519446 пишет:

цитата:

Потому что нетварь очень сильно использует память для кеширования и сбрасывает на диск новые данные ДАЛЕКО не сразу

Кто мешает "тонко" настроить кэш в Netware ? ;)

 Отправлено: 22.12.06 14:48. Заголовок: Re:

Dima пишет:

цитата:

Кто мешает "тонко" настроить кэш в Netware ? ;)

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

 Отправлено: 22.12.06 14:57. Заголовок: Re:

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

 Отправлено: 22.12.06 15:13. Заголовок: Re:

Григорьев Владимир пишет:

цитата:

однако ее завышенная цена делает эту систему недоступной для большинства Clipper-

Поднимите руку кто юзает ADS оффициально купленный ;)

 Отправлено: 22.12.06 15:25. Заголовок: Re:

Григорьев Владимир пишет:

цитата:

2. Мнение к DBF не предвзятое, а реальное. У DBF-системы нет понятия транзакции, поэтому использование их в многопользовательской системе делает их ненадежными.

Я не пойму, чем не устраивает терминальная система работы?

 Отправлено: 22.12.06 15:44. Заголовок: Re:

lista пишет:

цитата:

Если же использовать технологию терминал-сервер (например, в связке Linux+DosEmu, Linux-Clip),

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

 Отправлено: 22.12.06 15:45. Заголовок: Re:

Dima пишет:

цитата:

Поднимите руку кто юзает ADS оффициально купленный ;)

Вот это-то как раз и плохо!

 Отправлено: 22.12.06 16:01. Заголовок: Re:

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

 Отправлено: 22.12.06 16:18. Заголовок: Re:

lista пишет:

цитата:

Или поставить заказчику ОДИН Linux+Clip на сервер, а рабочие машины Telnet.

По сути дела это означает сменить специализацию с программиста на системного администратора!

 Отправлено: 22.12.06 16:30. Заголовок: Re:

Григорьев Владимир пишет:

цитата:

У DBF-системы нет понятия транзакции, поэтому использование их в многопользовательской системе делает их ненадежными

Зато у АДС оно есть. В том числе и для использования в .dbf. После того, как я перевёл свою систему на работу с транзакциями, ушёл в прошлое весь этот гимор с "непонятными" результатами в виде "частично" записанных документов, "странными" остатками на складе или на балансах клиентов и т.п.

Dima пишет:

цитата:

Поднимите руку кто юзает ADS оффициально купленный ;)

Требую прекратить издевательство над здравым смыслом! :-))

 Отправлено: 22.12.06 16:35. Заголовок: Re:

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

 Отправлено: 22.12.06 16:39. Заголовок: Re:

lista пишет:

цитата:

Да и не большая там "заморочка" установка Линуха

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

 Отправлено: 22.12.06 17:07. Заголовок: Re:

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

 Отправлено: 22.12.06 17:43. Заголовок: Re:

lista пишет:

цитата:

это намного дешевле, чем юзать Новелы или АДС, которые все равно не дадут надежности терминальных систем.

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

 Отправлено: 22.12.06 17:44. Заголовок: Re:

p519446 пишет:

цитата:

Винду - рабочая платная станция, которая валится, зависает, индексы рушатся..., т.е. требует обслуживания, восстановления БД вот куда нужно голову приложить.

И кто должен голову приложить к этой винде ? Программист-клипперщик, что ли ?!

 Отправлено: 22.12.06 18:09. Заголовок: Re:

p519446 пишет:

цитата:

Не согласен (по поводу АДС):

не важно, что правда, а что нет... главное, чтобы ты сам в это верил)

зы. мыло на яндексе игноришь?

 Отправлено: 22.12.06 19:33. Заголовок: Re:

p519446 пишет:

цитата:

2) без транзакций - да, не дадут. С транзакциями - не вижу причины, чем терминальная система надёжнее. Потому что если Ваш сервер рухнет посередине рабочего дня, эффект будет одинаковым% работал он на новелл+АДС или это был терминальный сервер.

С такой постановкой задачи и "сервер с транзакциями" не поможет, если он же рухнет "посередине рабочего".
Да и затраты для перехода на сервер с транзакциями какие?

А что Вы хотите:
- повысить нажежность
- повысить скорость
- остатся на Клиппере

Есть опыт запуска и на сетке до 10 машин и сетке из полсотни машин. Здесь запускали систему в начале на Целероне 2,0GHz и RAM 2Гб. Сейчас побольше машина, т.к. нужно делать выборки.

 Отправлено: 22.12.06 19:40. Заголовок: Re:

p519446 пишет:

цитата:

И кто должен голову приложить к этой винде ? Программист-клипперщик, что ли ?!

Так здесь эти вопросы довольно таки часто обсуждаюстя.
- что и как RegEdit подправить
- что в Новеле настроить
- протокол какой постаить, какой удалить
- ...

 Отправлено: 22.12.06 19:50. Заголовок: Re:

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

 Отправлено: 22.12.06 19:58. Заголовок: Re:

p519446 пишет:

цитата:

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

я с Юрчиком не согласен , можно сбацать ;)

 Отправлено: 22.12.06 19:59. Заголовок: Re:

lista пишет:

цитата:

Да и затраты для перехода на сервер с транзакциями какие? А что Вы хотите: - повысить нажежность - повысить скорость - остатся на Клиппере

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

 Отправлено: 22.12.06 20:14. Заголовок: Re:

p519446 пишет:

цитата:

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

У Вас, что сейчас на файл-серверной технологии работает 100 чел? И как?
Я видел, какая это работа на при 40-50 челах и Новел сервером. Удручающе. После перехода на Линух+Клип, больше не хотят возврата.

Для терминальной системы разрабатывать ничего не нужно! Сменил платформу и всЕ, т.е. назад к прошлому (МайФреймы).

 Отправлено: 22.12.06 20:25. Заголовок: Re:

p519446 пишет:

цитата:

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

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

 Отправлено: 22.12.06 20:50. Заголовок: Re:

p519446 пишет:

цитата:

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

Ни разу не замечал такого , все нормально открывается с первого раза.
Везде где ставлю прогу с поддержкой ADS , везде только Netware сервак.
Открытие баз в цикле это ты сильно замутил ;)
Готов обсудить вопрос , если интерестно.
Ты либо что то не то линкуешь или же что то чисто ADSовое не отрубил в самой программе.

6313 как правило бывает если не верно протоколы настроены или же сетевых карт в тачке больше одной ;)
на ровном месте она практически не возникает.

По ходу нужно еще и файервол правильно настроить если таковой установлен на рабочей станции , при чем
к каждому Firewall свой подход.

 Отправлено: 22.12.06 21:25. Заголовок: Re:

lista пишет:

цитата:

Начались сети. Пока 3-5 машини сносно и то..., а когда 20-30 вот здесь и началось, что Клиппер ни куда не годится. Хотя для локальной машины задача работала на Ура.

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

 Отправлено: 22.12.06 21:51. Заголовок: Re:

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

 Отправлено: 22.12.06 22:07. Заголовок: Re:

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

 Отправлено: 22.12.06 22:11. Заголовок: Re:

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

 Отправлено: 22.12.06 22:24. Заголовок: Re:

Dima пишет:

цитата:

У меня максимум клиентов в сетке под ADS больше 30 пока не превышало.

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

 Отправлено: 22.12.06 22:31. Заголовок: Re:

p519446 пишет:

цитата:

Так вот: чаще всего валятся именно эти, "ничего" не делающие тачки.

Офигеть , я не знал.............
В дальнейшем думаю очень пригодится , спасибо !!!!!!!!!!!!!!!!

 Отправлено: 23.12.06 01:10. Заголовок: Re:

Dima пишет:

цитата:

Чем и как корректно скопировать этот форум для локального просмотра ???

Например Offline Explorer

 Отправлено: 23.12.06 01:24. Заголовок: Re:

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

 Отправлено: 23.12.06 01:31. Заголовок: Re:

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

 Отправлено: 25.12.06 13:04. Заголовок: Re:

p519446 пишет:

цитата:

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

А я про, что говорю!!!
Вот эти, то проблемы и лечит терминальная система работы.
Возмите по-пробуйте. Что мешает?

 Отправлено: 25.12.06 16:48. Заголовок: Re:

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

ЗЫ. У нас в конторе есть терминальная прога (не на клиппере), на ней сидит около 60 человек. По недавнему признанию её автора, работа часто тормозится, особенно по утрам (в "часы пик"). Хотя сервак там нормальный, вроде бы.

 Отправлено: 25.12.06 17:24. Заголовок: Re:

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

 Отправлено: 25.12.06 17:41. Заголовок: Re:

p519446 пишет:

цитата:

А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ?

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

 Отправлено: 25.12.06 18:49. Заголовок: Re:

Григорьев Владимир пишет:

цитата:

И следовательно из базы данных нужно удалить те записи, которые уже успели туда попасть, а всю транзакцию пересохранить в базе данных заново.

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

 Отправлено: 26.12.06 16:40. Заголовок: Re:

p519446 пишет:

цитата:

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

Я в свое время тоже задавал такой вопрос.
Как мне объяснили процесс (задача) будет работать до тех пор пока не встретит на своем пути inkey() (на inkey()-реализован весь ввод с клавы), запрос на ввод данных с терминала. И если этого терминала на другом конце уже нет (закрыли крестом, пропало 220, выдернули кабель...) то, тогда программа вывалится с ошибкой.

На 50 юзерах я не видел перекособоченных документов (шапка есть, строк нет или частично нет). Реальный опыт больше 2-х лет.

 Отправлено: 26.12.06 17:18. Заголовок: Re:

p519446 пишет:

цитата:

Мне уже поздно что-то пробовать - слишком большая прога, слишком много усеров. Даже если в процессе тестирования не найду ни одной ошибки или трабла, это СОВЕРШЕННО не говорит о том, что когда будет реальная эксплуатация и все

Ничего не позно.
Куда я пришел было наверное тоже самое.
Хотел задачу запусить под ДОСЭМУ самое простое, но задача не собралась в Рела-моде. Только в Протек-моде, в это режиме под ДОСЭМУ не удалось решить проблему сжирания процессора.
Пересобрали задачу на Clip.
Первый сервер был Целерон 2гГц и памяти 1Гб тормозило только когда запускали большие отчеты. Но и то равномерно у всех.
На терминалах по-запускал все, что можно даже машины под чистым ДОС-ом. Скорость была таже, что на новом системном блоке - терминалы же.

p519446 пишет:

цитата:

Есть еще один момент: терминальная система работы предполагает ПОЛНОЕ отключение клиентских машин из вычислительной деятельности. Т.е. вся нагрузка по арифметике и работе со строками ляжет на хрупкие плечи сервера. А у меня в проге достаточно и арифметики и, особенно, операций со строками. Какие требования надо в таком случае предъявлять к серверу, чтобы усеры не видели задержек ? Какая у него должна быть память, диски, ЦПУ ? Имхо, совсем не такие как сейчас

Я не знаю задачи.
Но на юзера нужно порядка 4Мб памяти+система - да и памяти никогда не бывает много, диски - сам можешь прикинуть (брал сказевы физические зеркала).
Реально юзеров разделили:
- те кто набирает (здесь самое критичное)
- и те кто выборки делает (да и задачи у них написаны на Фокпро и доспуп в только в режиме чтения)
По ЦПУ взяли 2-х процессорную машину с гипертрейдами, т.е. Линух видет 4 проца. Система сама распределает потоки (задачи).

Код почти не переделывали, был глюк с длинными транзакциями, т.е. запись держали долго. Переделали на короткую, все ОК.
Уже перевели и три филиала на терминальную систему (была винда).

А перейти просто, можно даже частями. Собралась бы задача под Clip-оп.

Пробовать нужно. Хуже 100% не будет.

 Отправлено: 26.12.06 17:31. Заголовок: Re:

p519446 пишет:

цитата:

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

Во-во!
Так только в Клиппер появились множественные блокировки, я так и делаю.
- добавляю и блокирую
- записываю
- разблокировка
Только все это запускал сразу под ДОСЭМУ и затем под Клип-ом.
Проблем с этим нет работает!

 Отправлено: 27.12.06 17:52. Заголовок: Re:

lista пишет:

цитата:

Как мне объяснили процесс (задача) будет работать до тех пор пока не встретит на своем пути inkey() (на inkey()-реализован весь ввод с клавы), запрос на ввод данных с терминала. И если этого терминала на другом конце уже нет (закрыли крестом, пропало 220, выдернули кабель...) то, тогда программа вывалится с ошибкой.

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

 Отправлено: 27.12.06 20:18. Заголовок: Re:

p519446 пишет:

цитата:

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

Если говорить о серверной оси Линух, операции обработки баз данных не требуют наличия "живого" терминала. Что от туда ждать программе? Т.е. программа доработает свои 300 строк, дойдет до inkey() и отвалится.

 Отправлено: 27.12.06 20:42. Заголовок: Re:

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

 Отправлено: 27.12.06 21:08. Заголовок: Re:

p519446 пишет:

цитата:

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

Поставь например http://www.vmware.com/products/ws/

 Отправлено: 28.12.06 09:56. Заголовок: Re:

p519446 пишет:

цитата:

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

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

 Отправлено: 28.12.06 11:22. Заголовок: Re:

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