А какие реальные требования к серверу RK7?

[SH]

Собственно, сабж

[St@rch]

К железу никаких особых требований. К софту (ОС) тоже. Сейчас стоит все на 2003 сервере. Пробовали на XP и даже на WinPOSready и W7Starter...

Один раз в сутки нужно перезагружать сервер справочников и сервер отчетов (службы), чаще вылетает сервер отчетов. Инфа - самизнаетеоткуда

[SH]

К железу никаких особых требований. К софту (ОС) тоже. Сейчас стоит все на 2003 сервере. Пробовали на XP и даже на WinPOSready и W7Starter...

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

[St@rch]

Штук 10 кабаков по 6 станций фаст-фуд. Сервак - обычный DualCore с 2мя ГБ ОЗУ. Кстати, враги сообщили, что SRV03, на самом деле XPpro стоит. Но... Полет пока всего три месяца, умы ГСЫ говорят об озвученных тобой проблемах, когда база становится больше и больше.

[SH]

когда база становится больше и больше.

Ну вот база может стать больше уже за год. Не говоря уже про несколько лет. Конечно, умным проще раз в пару лет апгрейдится, но много ли таких умных...

[St@rch]

продолжаю наблюдение (с)

[BoniX]

Доброго времени суток!
Присоединюсь, с вашего позволения
Можеть быть, прибить тему, как основную по холиварам RK7?

Плюсы у рк6 в легкости настройки, и его полного понимания, это факт. Но уже приходится принимать это как данность, ведь ключи в скором времени могут прекратить продавать, и все. Можно наверное провости параллели между sh3 и sh4 как по самостоятельности по (базы и т.п.), так и зрелости в плане функционала. SH4 тоже не сразу хорош был ведь

К железу никаких особых требований. К софту (ОС) тоже. Сейчас стоит все на 2003 сервере. Пробовали на XP и даже на WinPOSready и W7Starter...

Один раз в сутки нужно перезагружать сервер справочников и сервер отчетов (службы), чаще вылетает сервер отчетов. Инфа - самизнаетеоткуда

Ради интереса, из за чего они у вас вылетают? куски логов?

По поводу перезагрузки раз в сутки - имхо, ерунда. Но, спецам виднее. Сервак работает 24/0 (как и ресторан), полгода, больше 20 станций, по 3 фр на каждой кассе.
Хотя конечно еще не время, наблюдаем.
Размеры пока такие:
check.udb 301 МБ
rk7.udb 25 МБ
rk7log.udb 37 МБ

База же кубов в SQL
RK7_CUBE_log.ldf 90 МБ
RK7_CUBE.mdf 304 МБ

Объемы пока смешные.

Система winXP с патчем терминала. 4гбОзу, Core i3, и рейд 1. Ибо все вяжется к железу сервака (какому?...) и work.udb каждого кассового сервера, и ключу (номеру его). Поэтому стабильность именно сервера важна (на станции пофиг, если только извращения вроде касс.сервера на кассе (ога, сервер в опытных руках официантов)), хотя все лицензии можно на ходу сделать дилеру... Горел ключ - сос на другой, не проблема. Вот только баз бэкапы и еще раз бэкапы.

К железу требования самые нормальные по современным меркам. И прямопропорционально объемам. Хотя, сервер то, обычное soho стабильное.


П.С. Игорь, ты сам пробовал запускать и настраивать? Ведь, как я понял, пока только наблюдения коллег, или ошибаюсь? Ибо как можно узнать, что сахар сладкий, не пробовав его никогда ) Хотя, я еще как понял, ucs отлаживают все на surrent ветке (оно и понятно). Кстати, вопреки всему стабильаная ветка продолжает выходить (7.3.9.35 вышла). Так что может дело в этом.

Сейчас upgrade'им следующий ресторан на rk7 (сами захотели), без остановки.
Конечно сложно изначально с понятием логики работы и запоминания настроек. Ведь настроить можно все, но изначальные настройки подходят далеко не всем.
Зато радует, что все в одном месте по одному ярлыку. Разве что мониторинг сделан web-приложением (хотя кроссплатформенность).

Прошел второй этап запуска, остались плюшки ввиде обучения персонала, изменение идеологии относительно изначально забитых столов в системе (левый не завести), а уже на стол можно добавлять независымые заказы, 4.1 и т.д.
Что разбивать заказ на разные нужно лишь только в случае обслуживания разными официантами, ( а по большому счету, может один заказ сразу обслуживаться основным и дополнительными официантами), а чтобы гостям дать раздельные счета, нужно только возле блюд проставить цифру места, а кассиру нажать кнопку "пречек по местам" ну и чек по местам.
Что системе можно указать резервный принтер в случае отказа основного заранее, по логике. И не нужно будет бегать в панике за тем, кто может поставить галочку в 11 часов вечера. О том, что можно ставить время подачи блюда, и потом отправить напоминания (или автоматом настроить заранее), и отложить печать до нужного времени в принципе. Что еще не утихнет звук от нажатия ОК, как действие уже произошлО, на всех кассах это уже появилось , изменилось.. На одной станции одного ресторана, на всех станциях десяти ресторанов.. (выключать синхронизацию с серверами на время глобальных правок).
Что не нужно никаких спридов и расшаренных принтеров с собачками, теперь никаких бухгалтерских балансов на кухонном принтере.
Что разбитие по фр делается не костылями, а теми же классификациями. И "ловлей на классификацию" основного фр и перенаправления этих блюд на указанные фр. Что наконец можно построить абсолютно любой отчет, и распечатать его с абсолютно любыми данными.
А не та печатная форма из "списка чеков", в которой даже даты чека нет, официанта, стола, времени. ничего ttttttt и на все это есть только invoice с одной единственной формой этого чека, которую только можно править
Paradox с его безопасностью уровня школьника и стремлением к суициду. Чудеса вроде кассовых серверов на ноутбуке в зале в принципе невозможны. Говорят, шифруется, по умолчанию. И сервер до кучи не запустить просто так.
Никаких незакрытых / перезакрытых вперед дней (хотя и там костылик ввиде logicdate имеется).

Но везде есть свои грабли.
Вот только столкнулся сегодня: Делал импорт rk6-rk7. Выгружал только меню и классификации (категории т.е.). А валюты и пр. оставил предустановку из базы, благо уже настроенное. А по поводу sh4 забыл, что там выгрузка по валютам идет.
Меню по сифрам замечательно совпало!
А вот sifr валют в недрах sh4 от rk6 (c кучей документов расхода) совсем не был равен sifr предустановленных валют в rk7. И там и там их поменять нельзя (логично). В итоге "новые" для sh4 сифры выгрузились из rk7, а совпавшие только поменяли имена на rk7шные. Теперь те док.расходы, что были на нал, стали "картой отеля" и прочий бред. До кучи еще причины удаления другие...
Кто - нибудь знает, как поменять sifr или в в sh4, или rk7?
Хотя, надежда на техподдержку
Можно конечно сделать killdoc, но ведь делали меньше полугода назад, людям и так сейчас головной боли добавилось, а проблема то выеденного яйца не стоит...

[czm84]

Хотя, я еще как понял, ucs отлаживают все на surrent ветке (оно и понятно). Кстати, вопреки всему стабильаная ветка продолжает выходить (7.3.9.35 вышла).

И по-моему была последней. Сейчас разделение на две ветки — current и stable — убрали.

[VampireKB]

Немного демагогии и собственного опыта насчет баз...
База UDB ,- это закрытая база данных без внешних сервисов и дров. База имеет возможность выгружаться в память,но на 90% работает с жестким диском.
Эта характеристика идентична той,на которой работает и моя база(.FIG) для ПО "ЦПДСС" и именно по-этому отчеты с неё грузятся секунды при малых объемах и минуты при большых(более 100 000 строк)
Именно по-этому я у себя сделал выгрузку в Postgres ,а ГСЫ в SQL Server 2005\2008 . .. Уверен,что если принаровить отчеты 7ки к SQL ,то и падать она будет реже(падает скорее всего по таймауту) и работать намного шустрее...

Текст письма в тех.поддержку моей базы данных год назад:

> 1)What is the main point for your DB ? Memory or processor ?
> Because it makes a select Query for about 30 seconds ,when the
> recorccount is more then 1 000 000

Disk I/O speed is the most important point.
If you can use in-memory tables, or create indexes it could speed up your query.

[SH]

BoniX, спасибо!
Не понял только, зачем тему прибивать