| [Форум] [Помощь] [Поиск] [Выйти] |
Добро пожаловать, ![[info]](userinfo.gif){kind=small} User
|
|
|
| ||
| У кого уже есть опыт, подскажите, как сделать следующее: Есть справочник "Номенклатура" и справочник "Склады". Справочник "Склады" подчинен справочнику "Номенклатура" На основной форме элемента справочника "Номенклатура" размещена талица справочника "Склады". Когда в справочник "Склады" добавляем новый элемент, нужно проверить, не вводили ли такой склад.... что то у меня не получается :)) |
| ||
| Я зашел в тупик при попытке повесить обращение к процедуре модуля на кнопке формы :) Так мечтал, что бы восьмерка меня миновала :( |
| ||
| Дим, а ожно поинтересоваться с какой целью 8.0 понадобилась? чего в 7.7 не хатает? или змыслил обновить парк рабочих станций? :) |
| ||
| Даже не знаю. 40 одновременно работающих пользователей. Не знаю, выдержит ли 7.7 SQL такой натиск? DBF давно уже не справляется. Слово "Транзакция" я слышу постоянно. |
| ||
| "7.7 SQL такой натиск?" ясен пень выдержит... сервер только больее-менее приличный нужен. в последних релизах вполне адекватно она себя ведет... а не проще попробовать уложить базу в ms sql хранилище, чем полностью переписывать аконфигу под 8.0 и переводить на неизвестно как работающий софт свое предприятие? |
| ||
| У меня сейчас круто кастрированная версия 8.7. Ковыряли до меня ее очень активно и настолько нерационально, что простой перевод этой конфы под SQL ничего хорошего не даст. Пробовал уже. Игорь, посоветуй по железу для SQL... У нас один уже есть 2хКсеон 4 гига оперативки, второй будем брать чисто под SQL. Тоже 2хКсеон (а может что то другое попробовать?) и вот сколько туда оперативки? Может все 6 слотов по гигу забить? А конфигу все равно надо писать с нуля.Хоть и под 7.7. Ничего типового не подмять под нужды наших командиров. |
| ||
| дык теперь знаешь,что и как вот и нарисуй новую оптимзированную конфигу под 7.7. непонятную и необъезженную восьмерку, которая неизвество что может выкинуть накакой? а какой сервер это нао смотреть от того, какой разер базы и что в ней делается... "может что то другое попробовать?)" это не утюги от amd я надеюсь ты говоришь? :) |
| ||
| Ни фига себе, это какой должен быть тупой продукт чтобы из-за полсотни пользователей вешаться на двухкамневом ксеоне :( |
| ||
| Он не тупой, он универсальный ;-) |
| ||
| Вам показать? |
| ||
| Запусти sql profiler и посмотри ЧТО за запросы он там делает ;) Дальше 2 варианта: если тебе с этим работать - то плачешь, если нет - смеешься :) Так что сам MS SQL Server (особенно 2005) - это очень хороший продукт, вопрос вариантов его испольования остается открытым :) |
| ||
| у 7.7 хоть SQL, хоть любая другая одно вущественное ограничение - блокировка на журнал документов при проведении/добавлении Потому транзакция будет всегда когда модуль проведения долго выполняется или когда идет групповое проведение. В эти моменты все остальные в любом случае будут курить, какой бы мощный сервак не был. в 8ке эта проблема решена, в остальном смысла переходить нет |
| ||
| в свойствах базы option-recovery-model лучше установить simple. в свойствах пользователей поставить время ожидания захватататаблиц поболее. и пожалуй модули проведения надо бы оптимизировать... у меня очень редко появляется это сообщение и то, когда перепроводят инвентаризациоенные ведомости, где кол-во строк до 25000. |
| ||
| Где то вычитал, что в 7.7 способ ожидания захвата сделан неочень удачно... во время этого ожидания процессор сильно забивался и когда уходили на ожидание несколько пользователей, то начинался чистый столбняк. Сейчас применяю внешнююю компоненту, которая заменла стандартный обработчик ожидания. Выставил ожидание 3 секунды. Транзакций стало заметно меньше, но все равно они есть и они ДОСТАЮТ!!! |
| ||
| А что, даже ожидание захвата делается НЕ на уровне SQL-сервера, чтоли? Там же это, так сказать, нативно... :-/ |
| ||
| у Oldman-а файловая версия... |
| ||
| Ааа! :) Тогда сорри :) |
| ||
| "вущественное ограничение - блокировка на журнал документов при проведении/добавлении..... В эти моменты все остальные в любом случае будут курить" А что мешает настроить эти блокировки? Отсутствие знаний? RTFM. Если уж ваще лень копаться то почитай книжку по ToySQL там про блокировки как для ребёнка расписано и есть готовые ХП и будет тебе счастье. ;-) Ну и самый простой способ оптимизировать проведение, как Peps сказал..... |
| ||
| У тебя сама платформа стабильно работает? |
| ||
| Стабильно :) Стабильней некуда. |
| ||
| 1. Поставил из коробки релиз 8.0.9. 2. Для перехода на 11-ый надо поставить сначала десятый. 3. Конфига работает только на 12-ом. 4. Для установки 12-го, надо сначала деинсталировать 11-ый :) 5. Конфига не проходит тест и с ошибкой вылетает, искал в инете описание кода ошибки и нашел только, что это самая страшная тайна 1С :) 6. После повторной полной переустановки, вроде заработало. |
| ||
| Усложняем задачу. Пользователей в итоге (итог наступит где то к лету следующего года) будет около 200. Что то я засомневался в возможности 1С 7.7 вытащит такое количество пользователей и нормальной работы... Что мы имеем: Терминальный сервер 2хКсеон 1.7 гигагерц, 2 гигабайта оперативки, РАИД 10 из 4-х винчестеров. SQL сервер: 2хКсеон 3.6 гигагерц, 6 гигабайт оперативки, 6 винтов в РАИД-массиве 10 (адаптер с 256 мегабайтным кэшем) Серверы будут увязаны гигабитным (а возможно и двумя) шнуром. На терминальном ползают юзеры, SQL ворочает базу. Номенклатура где то порядка 30 тысяч наименований, документооборот большой. Одновременно могут проводить до 10-20 документов по 10-150 строк в каждом Вот и думаю, вытянет 1С 7.7 на таком железе до 200 активных пользователей или умрет через месяц? Ответы типа "Должно вытянуть" - не принимаются. |
| ||
| "На терминальном ползают юзеры..." Этот на таком железе уже после 50 начнёт тормозить....;) У меня на 54 - ом пользователе началися жуткие тормоза...... Тут подходит стандартное решение. |
| ||
| У меня сейчас 60 юзеров и на этом же сервере крутится база.. А стандартное решение не подойдет... Может тогда несколько термпинальных серверов? :) |
| ||
| Что за стандартное решение? |
| ||
| Как я понял - это на каждой рабочей станции по 1С стоит и они работают с SQL |
| ||
| Понятно. Есть смысл поделить базы (например по отделам, группам отделов, подразделениям). |
| ||
| "Как я понял - это на каждой рабочей станции по 1С стоит и они работают с SQL " + настройка блокировок, ну и соответственно всё остальное. В дальнейшем пришли к разбивке базы и репликации на серваке.... Всё работает. Если уж ставить такую штуку как SQL Server, то нужно заставлять её работать.... А клиент пофик какой, хоть 1С, хоть чёрт лысый.... 200 человек тьфу для скуля. (повторяюсь, как и писал в письме, у нас стока нет, но что то около того ;-)) ну железо ещё хорошее.... |
| ||
| Можно про разбивку и репликацию поподробнее? |
| ||
| Сейчас 110 человек прописано в базе но активных в среднем порядка 50. Тормозов незамечено, стоит цитрикс с dbf, база 1,5 гига |
| ||
| Так у тебя база маленькая.... 1,5 Гб это с индексами или только двф? |
| ||
| это для файлово версии то маленькая, еще в половину вырастет и вообще практически перестанет шевелится... писать в нее более-менее еще можно будет, а вот читать-труба... |
| ||
| Да нет.... Шевелятся и довольно быстро.... Вот переиндексация такой базы это нечто:) Довольно сильные ощущения:) Только вот всему наступает предел и у меня он наступил, когда один из файлов перешагнул предел в 1,12 Гб. |
| ||
| "Шевелятся и довольно быстро...." привыкли видимо... :) 1.12гб-бух компонента? |
| ||
| Ага, именно она, бухгалтерия. Файл 1SENTRY.DBF - 1,12 Гб |
Отправил