Имя: Пароль:
1C
1C 7.7
v7: 1С Комплексная, лавинообразно начали сыпаться ошибки. Помогите пролить свет.
,
0 maxnn
 
10.04.12
13:57
Имеем базу Комплексну - файловую. База доработана сильно. Размер базы 7 гигов. Самый большой ДБФ 1.3 Гига - это общий журнал.
60 Пользователей онлайн, 1000 документов в день в срднем.

До прошлой недели всё просто летало идеально. Потом  обновили релиз с 493 на последний, сохранив все доработки соответственно. После этого намного чаще начала появляться ошибка транзакции, что таблица занята пользователем и так далее. Но работала ещё сносно. К концу недели база вообще стопорнула.
Полезли ошибки DATABASE ERROR 110, ругаясь на индексный файл.
Тестирование и исправление, удаление индексных файлов и загрузка-востановление базы не помогло. При создании документа всегда выдавалась ошибка транзакции.

Был обратно загружен старый релиз 493, правда план счетов остался новый, чтобы не пересчитывать итоги, так как делалось в рабочее время.
После этого на несколько дней ошибка DATABASE ERROR 110 пропала, но работать в базе было не возможно из-за транзакций. из 100 документов создавалось несколько.


В итоге щас из 60 человек в базе работает 2-3 чловека. заходит больше, снова лезут ошибки DATABASE ERROR 110  и ошибка транзакции. Помогает только выкидывание всех пользователей, переиндексация базы и запуск опять 2-3 пользователей. И это пока не зайдут ещё несколько.

Из за чего такое могло возникнуть и есть ли какие пути решения кроме SQL? Интересует также, из за чего так внезапно всё накрылось. База работала идеально.


P.S. Пока что решили чтобы быстрее вернуть базу - это перейти на SQL. Но из-за существенных затрат на это ищется также альтернативные пути решения.  Вообще думалось, что до 2 гигового лимита база проработает 3 года. Уже идёт 3-тий год. В конце года планировалось просто свернуть базу и работать следующие 3 года без проблем.
154 opty
 
11.04.12
01:31
Но скорость несколько упадет
В некоторых случаях чуть чуть , в некоторых случаях скажем так - заметно
Возможно придется переписать некоторые отчеты (запросы) а может и нет
155 opty
 
11.04.12
01:44
В общем если этот обор отключен программисту будет тяжелее строить отчеты непосредственно к проводкам , именно в разрезах номенклатуры , ибо отбора нет , всякие там ВыбратьПоЗначению() , но на самом деле это требуется достаточно редко . Бухзапросы просто замедлятся в некоторых случаях .
Например оборотка по 41 за месяц целиком будет строится с такой же скорость как и раньше , а вот напрмер оборотка скажем с 1-го по 15-е , может будет строится в два-три раза дольше , ибо там сам запрос выбирает проводки , а отбора-индекса то и нет

Стандартный размен - объем на скорость :)
156 romix
 
11.04.12
01:50
Чегой-то hogik-овые статьи на Инфостарте все удалены
http://www.peeep.us/41557f35
157 maxnn
 
11.04.12
01:51
(156) Он удалил все свои наработки с Инфостарта.
158 opty
 
11.04.12
01:53
16777215 вот оно волшебное количество записей в DBF при котором начинается кабздец
159 opty
 
11.04.12
01:55
При стандартном Kernel :)
160 maxnn
 
11.04.12
02:00
(158) оппа... У меня в 1saccsel 16 835 204 записи... Так занчит у меня из-за него база полетела?
161 maxnn
 
11.04.12
02:00
И какие последствия могут быть, если в таком режиме у меня несколько дней проработала база?
162 opty
 
11.04.12
02:04
(143) Если есть готовый инструментарий для свертки (стандартный желательно допиливать) то все упирается в объем базы и мощность железа . Сама свертка ну несколько часов идет если правильно все делать .

Месяц назад сворачивал свою скульную базу на миллион доков за 2011 , за все про все 9 часов , включая репликации , инструментарий естественно уже готов был .

(160) Ога :(
(161) Самые тяжелые :(
163 maxnn
 
11.04.12
02:07
(162) А Kernel137 этот лимит поднимает до 2 млн всего лишь?
164 maxnn
 
11.04.12
02:07
(162) И как мне последствия такой работы проверить? Просто перепровести доки за последнюю неделю и всё встанет нормально?
165 zak555
 
11.04.12
02:09
(164) см. (145)

ты будешь не движения формировать, а итог сразу за месяц по всем документам за период
166 romix
 
11.04.12
02:09
(158) FFFFFF в шестнадцатеричной системе однако
(0) 60 пользователей это много для ДБФ, выгружайте в SQL, если не выгружается то есть опять же патч (я пейсал). Книга знаний: Плагин для лечения выгрузки и загрузки больших баз в 1С 7.7
167 opty
 
11.04.12
02:14
(163)Плюс минус , несколько поможет , но ...
(164) Не факт , могли доки вообще потеряться , хотя у тебя врят ли , проблем с 1SCRDOC нету , не записались проводки , или док удален а проводка осталась (свободная проводка)

Все таки КАЧЕСТВЕННЫЙ переход на скуль , особенно большой и сильно переписанной базы , дело не одного дня , если по уму , и активно используемая бухия однако то же вопросы вызывает.

Срочная свертка , или срочное отключение отбора , даст время на размышления
168 maxnn
 
11.04.12
02:17
(167) Только что отключил отбор... После реорганизации количество записей в 1saccsel  не изменилось. Размер остался тот же. Все изменения делались в течение 15 минут. При сохранении файл 1saccsel был создан заново.
169 maxnn
 
11.04.12
02:18
(167) Есть какие мысли?
170 maxnn
 
11.04.12
02:19
(166) А модифицированная kernel37 до какой планки поднимает тогда это число?
171 opty
 
11.04.12
02:23
Так , конфигуратор-проводка посмотри какие отборы стоят
Может стоять только  разрешить отбор , а может еще по дебет-кредиту и для всех
172 romix
 
11.04.12
02:25
(167) Да какие там вопросы. У нас всю жизнь была SQL везде. Гораздо кошернее и стабильнее.
(170) 2 гига на файл у них физический предел (лимит для целого числа со знаком).
173 opty
 
11.04.12
02:26
Если стоит только галка "Разрешить отбор" тогда плохо , её лучше не отключать
174 opty
 
11.04.12
02:27
(172) Стабильней - абсолютно точно , масштабируемей , и плюшковатей
175 romix
 
11.04.12
02:28
(174) Экспертам НАСА виднее :-))
176 opty
 
11.04.12
02:30
(175) НАСА уже перешли на 1С в связке со скулем :))
177 maxnn
 
11.04.12
02:33
(171)  У меня стоит галки в "Разрешить отбор" и "Для всех".

Какие дальше действия Кэп?
178 romix
 
11.04.12
02:34
(176) Да они даже на метрическую систему перешли с дюймовой. http://science.compulenta.ru/301905/ С проста ли.
179 zak555
 
11.04.12
02:35
(178) РФ пустит штаты на луну ?
180 opty
 
11.04.12
02:37
Ну можно снять все галки вообще :)
Тогда у тебя этот файл просто исчезнет , некоторые отчеты в которых задействован отбор счетов будут считаться медленно , очень медленно
Ними калку Для всех , и попробуй установить количество уровней 1 , файл должен уменьшится заметно
181 opty
 
11.04.12
02:38
Сними галку для всех , в смысле :)
182 maxnn
 
11.04.12
02:39
(180) Снял... Идёт сохранения...
А на что это отразиться?
183 maxnn
 
11.04.12
02:42
Я вот что заметил. Копаю щас файл 1SACCSEL сегодняшний в DBF Viewer 2000.

В этом файле первое поле ab  Accid, так вот напротив этого ab стоит везде зелёная галка, а в конце файла на нескольких сотен записей вместо зелёной галки стоит красный крест.

О чём это может говорить?
184 maxnn
 
11.04.12
02:43
Повторюсь, количество записей 16 835 204.
В копии базы до того как появились проблемы кол-во записей 16 592 499
185 opty
 
11.04.12
02:47
(182) Перестанут работать отборы по счетам , точнее по субсчетам в журнале проводок , это ерунда
Перестанет работать програмный отбор по журналу проводок по субсчетам , используется редко , то же ерунда

А вот то что выполнение бухзапросов к субсчетам замедлится и довольно сильно , не очень хорошо , оснобенно не за цельный месяц . Если отбор отключит вообще то в разы
186 opty
 
11.04.12
02:49
(183) Это может говорить о том что давно не делалась упаковка таблиц базы
187 maxnn
 
11.04.12
02:51
(185) Сохранились изменения. 1SACCSEL стал вместо 730 Мб 236 Мб. Количество записей с 16 млн уменьшилось до 6 млн.
188 opty
 
11.04.12
02:56
(187) Сбоить по блокировке не будет :)

Теперь надо будет уточнить у программиста , работает ли он напрямую с журналом проводок , есть ли специфические отчеты , и не использует ли он в них отборры по счетам , если нет то просто следить за общим падением быстродействия бух отчетов и документов использующих запросы к бух данным .
Если в целом падение быстродействия не критичное , так и оставить :)
189 opty
 
11.04.12
03:00
Не плохо было бы сделать бэкап базы (скопировав всю базу) , а потом сделать выгрузку загрузку , базы , ну или как минимум тестирование-исправление с упаковкой таблиц ,после того как в рабочей базе будет отключен отбор для всех , и оставлен отбор по первому уровню счетов .
190 maxnn
 
11.04.12
03:07
(189) А по сути, для чего мы это делали если у меня стоит уже модифицированный kernel37? Он же это ограничение снимает?

Как я понял 16777215 это и есть проблема 2-ух млн строк?
191 opty
 
11.04.12
03:17
(190) Недокументированный метод :)
kernel37 в основном снимает ограничение на размер файла в 1 гбт . Несколько по другому строит индексы в DBF , вылетов и блокировок скорее всего не будет , но по поводу корректного построения отчетов на таком количестве записей могут возникнуть проблемы .

Больше 16777215 не надо , никаких гарантий корректности
192 maxnn
 
11.04.12
09:01
(191) Не помог kernel37, всё равно полезли ошибки когда все в базу вошли.... Щас удаляю отбор у номенклатуры и в проводках на рабочей базе...
193 opty
 
11.04.12
09:18
(192) После удаления отборов , все равно сделай тестирование-исправление , и обязательно проверить код на использование программных отборов .

Если количество движений по субсчетам счетов распределено не равномерно , сильного замедления бухзапросов не будет бли отключении отбора по счетам "Для всех" и ограничении одним уровнем . А по уму так надо базу смотреть , так трудно сказать
194 Ёпрст
 
11.04.12
10:28
(91) Сыми галку отбор по счетам и этой таблички не будет вовсе, твои бухи один хрен его не используют.
195 Ёпрст
 
11.04.12
10:29
именно из-за этого файла у тебя все ошибки сейчас.
196 Ёпрст
 
11.04.12
10:29
(192) не надо этого делать.
197 Ёпрст
 
11.04.12
10:29
+ нужен именно kernel33, а не 37
198 opty
 
11.04.12
10:44
(194) Используют , но не явно :)
Полностью снимать отбор со счетов не рекомендуется , а вот ограничить первым уровнем вполне компромисный вариант
199 Ёпрст
 
11.04.12
10:46
(198) ерунда это всё..
Для комплексной, всё можно.
+можно в разы уменьшить файло проводок.
200 opty
 
11.04.12
10:46
200 :)
201 opty
 
11.04.12
10:48
По уму , для комплексной вообще можно проводки за месяц формировать по итогам опер учета , но у ТС , бухгалтера так не хотят , в результате бухия очень сильно раздувается
202 opty
 
11.04.12
10:49
+(201) И нужно вообще то :)
203 Ёпрст
 
11.04.12
10:49
(201) там всё делается гораздо проще.
204 maxnn
 
11.04.12
12:07
(193) После Снятии "отбора" и "для всех" база заработала нормально.

(197) А разве kernel37 это не тот же kernel33 только ещё с исправление загрузки процессора при ожидании?


(202) Буду прорабатывать этот вариант.
205 Ёпрст
 
11.04.12
12:09
(204) нет
206 maxnn
 
11.04.12
12:11
(205) В текстовом файле идущем с библиотеками вот что было сказано
"В комплекте имеется файл Kernel37.dll. Эта библиотека решает (кроме проблемы 1 гигабайта) еще и проблему “100% загрузка процессора при ожидании блокировки”."
207 Ёпрст
 
11.04.12
12:14
(206) всё вопросы к автору
http://infostart.ru/profile/304810/

37 - раньше была для других решений, типа адвантадже
208 FN
 
11.04.12
12:48
(158) откуда инфа? есть авторитетные ссылки?
а то я проексперементировал - забил справочник 16977214 элементами и "кабздец" не наблюдаю

вот про >1 гБ - с этим сам сталкивался, а про (158) - не в курсах...
209 Ёпрст
 
11.04.12
12:51
(208)
Ошибка возникает при непосредственном удалении записи (в терминах 1С) в таблице с количеством записей более 16777215 штук.
Ошибка возникает при непосредственном удалении записи (в терминах 1С) в таблице с количеством записей более 16777215 штук. Удаляемые записи могут располагаться и до этой границы. Сообщение об ошибке указывает на индекс "IDELETED" с индексным выражением "D" и выражением фильтра "DELETED()". Этот индекс используется для нахождение помеченных на удаление записей (в терминах DBF) и размещения на их месте новых добавляемых записей в таблицу.
Первые кандидаты на такой количество записей: 1SCRDOC, 1SACCSEL.
Способов устранения проблемы, пока, не найдено.
Мнение разработчиков по поводу этой ошибки:
http://www.codebase.com/support/kb/?article=C01054
Допускаю, что такое проявление ошибки было привнесено именно в 1С. Т.к. продукт "CodeBase" продаётся с исходными текстами и "встраивался" в 1С с некоторыми изменениями на уровне исходных текстов разработчиками 1С. Само ядро "CodeBase" находится в библиотеке DBEng32.dll. Эта библиотека одинаковая для версий 1С: 18, 25, 27. Другие версии не проверялись.
Временное решение проблемы в ручном режиме.
Суть способа:
Отключить индекс "IDELETED" для проблемных таблиц. Естественно, отключится механизм использования помеченных на удаление записей (в терминах DBF). А это приведет к более быстрому росту размера таблицы. Частично решает проблему установка "Kernel3x", т.е. снимается ограничение на размер DBF файла в 1 гигабайт. Но при использовании данной разработки категорически нельзя использовать прямые запросы на FoxPro. Кроме этого придется чаще (регулярно) выполнять упаковку таблиц и внимательно отслеживать рост размера таблиц, т.к. существует ограничение на размер DBF файла в 2 гигабайта.
Последовательность действий:
1) При возникновении ошибки -310, на любой рабочей станции, срочно выгнать всех пользователей из 1C. Не сохранять никаких открытых форм ввода информации. Прекратить (прервать) выполнение отчетов. И т.д. Если произошёл сбой при выполнении регламентных работ, то восстановить базу с последней копии. При этом заранее оповестить всех пользователей об возможности появления такой ошибки и довести до них информацию о действиях в таком случае.
2) Т.к. в сообщении об ошибке -310 не выдаётся имя таблицы, то необходимо найти эту таблицу силой ума или тупым открытием подряд всех DBF-ов в порядке от большего размера файла к меньшему. Ищем таблицы в которых количество записей подбирается или уже больше 16777215 штук.
3) Удалить все CDX файлы. Зайти в сессию 1С монопольно и выполнить, тем самым, реиндексацию.
4) Вызвать утилиту обслуживания DBF/CDX структур. Например, бесплатную утилиту "Advantage Data Architect" можно скачать по ссылке:
http://devzone.advantagedatabase.com/dz/content.aspx?Key=20&Release=13&Product=8&Platform=6
5) Открыть проблемную таблицу в формате "FoxPro (DBF/CDX)". Вызвать свойства таблицы. Выбрать закладку с описанием индексов. Найти индекс "IDELETED". Изменить выражение фильтра с "DELETED()" на ".F.". Сохранить изменения с реиндексацией. Закрыть таблицу.
6) Открыть таблицу "1SUSERS" (DBF файл без индексов). В поле "USRSCNT" установить значение больше нуля. Закрыть таблицу. Выйти из утилиты.
7) Запустить сессию 1С в монопольном режиме. Согласиться с реиндексацией.
Дополнительная информация:
1) Необходимо повторять действия по отключению индекса после каждого удаления файлов CDX. После реиндексации без удаления файлов повторять отключение индекса не надо.
2) Данная технология проверялась только на тестовой базе. В промышленной эксплуатации - нет возможности проверить, т.к. у нас не возникала ошибка -310 при использовании "родного движка" и мы уже давно перешли на другу СУБД.
3) Надеюсь найдутся заинтересованные люди, и напишут утилиту для автоматического анализа проблемных таблиц и не ручного отключения
©hogik
210 Он
 
11.04.12
12:51
Ромикс уже считал. В файле может быть 2 млрд.записей (_StrToId("ZZZZZZ"
))
211 FN
 
11.04.12
13:05
(209) ага... вот где собака порылась.
Значит если непосредственно удаление запрещено, то в принципе работать со справочниками/документам можно. Главное что бы системные таблички (итоги, движения регистров и тп) не пухли
212 Ёпрст
 
11.04.12
13:12
(211) читай внимательнее, дело не в "непосредственном удаленинии объектов"
213 FN
 
11.04.12
13:17
(212) дык вроде внимательно прочитал. Вот на примере справочника - в идеальных условиях "удаленных" записей  у нас быть не может. Естественно к движениям регистров, итогам, 1scrdoc и тп это не относится - там движок сам "удаляет"...
214 Ёпрст
 
11.04.12
13:18
(213) так и есть.. думал ты про 1SCRDOC речь ведешь
215 Ёпрст
 
11.04.12
13:19
я ужо неоднократно упирался в это ограничение.. на 1SCRDOC
216 FN
 
11.04.12
13:25
(215) у меня _1SACCSEL давно за 20 перевалил и RA1051 уже 15
а вот _1SCRDOC всего 7
но конфа не типовая, так что видимо взаимосвязей между доками меньше чем в типовых.

Спасибо за разъяснения.
217 Ёпрст
 
11.04.12
13:33
(216) сыми отбор по счетам и.. 1SACCSEL  исчезнет
:)
218 opty
 
11.04.12
13:50
(217) Ага , а потом тащись как удав по шкурке №5 от скорости исполнения такой конструкции
Ит.ВыполнитьЗапрос(Дата1, Дата2, Счет, КорСчет, Валюта, 3, ВидПериода)
особенно когда Дата1 и Дата2 не равны началу и концу месяца
А если Счет и КорСчет списки то вообще

Совсем отбор по счетам убирать нельзя , в теории и с DBF можно вообще без индекса работать , но как то не очень
219 Ёпрст
 
11.04.12
13:56
(218) фигня это всё, в комплексной всё можно, если грамотно порезать аналитику в проводках, которая дублируется регистрами
220 opty
 
11.04.12
14:05
(219) Разговор не идет о том что МОЖНО в комплексной , разговор идет о выплнении запросов к бухгалтерским данным , и о влиянии на это отборов .

Можно вообще все на регистрах сделать , в теории , "умельцы" вон складской учет на одних справочниках пишут .

У ТС бухгалтерская часть в комплексной "живая" , о чем и писал выше , и да это не самый оптимальный вариант , но уж так повелось , и вопрос в том что ему надо было сейчас что бы заработало , чем когда нибудь правильно . Если он сейчас полностью отключит отборы по счетам , база может встать колом , не известно что и как там дописано по бухкомпоненнте . Даже отключение "По всем" оставляло такую теоретическую возможность (правда очень незначительную)
221 Ёпрст
 
11.04.12
14:07
(220) база не встанет колом, это раз.
Комплексную оптимизировать надо изначально, это два.
222 opty
 
11.04.12
14:10
(321) Комплексную оптимизировать надо изначально - 100 % согласен
Если полностью отключить отборы по счетам , при "живом" проведении по счетам в реальном време (с расчетами остатков и средневзвешенной) встанет
223 opty
 
11.04.12
14:11
Или по крайней мере имеет значительную вероятность
224 Ёпрст
 
11.04.12
14:20
(222) не встанет, проверенно на 20 гиговой базе в дбф
225 opty
 
11.04.12
14:22
(224) Круть , а че до 30 гиг на DBF не довели ?
226 Ёпрст
 
11.04.12
14:25
(225) предел в 2 гига на файло достигли, пришлось резать
227 maxnn
 
11.04.12
14:32
(226) А можно узнать причину того, почему на SQL не переходили?
228 Ёпрст
 
11.04.12
14:49
(227) зачем ?
229 Ёпрст
 
11.04.12
14:50
платить за скуль и его лицензии как-то не улыбает
переписывать все модули проведения, чтоб доки "ездили" быстро  - тоже.
230 opty
 
11.04.12
14:50
Относительно небольшая (средняя) бух база - чуть больше 4 гиг
1SACCSEL около 9 миллионов записей

Стандартная синтетеческая оборотка по субсчетам с включенным отбором по счетам за период 15 окт - 15 дек строится 2.5 сек , если отключить отбор полностью ,7.5 секунд .
С одной стороны мелочь 5 сек , с другой стороны в три раза дольше .

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

Если же постоянно , при проведении каждого документа расчитывать данные (остаки например по счетам) , да еще и по полной аналитике , далеко не фигня .

У ТС как раз второй случай .

(228) Интересно сколько идет реиндексация или тестирование исправление такой базы , кроме шуток интересно
231 Ёпрст
 
11.04.12
14:51
а если тупо в скуль закинуть - на наших объемах всё колом встанет, проверенно.
232 Ёпрст
 
11.04.12
14:52
(230) на одном серваке 30-40 минут, на другом 15-20, это реиндекс.
ТиИ не делается по причине отсутствия в его необходимости
233 opty
 
11.04.12
14:53
(231) Об этом тоже писал выше , нормальный переход на скуль, дело не быстрое , и к ней надо готовится , тем более не известно что там подонаписано
234 maxnn
 
11.04.12
14:55
(229) Эх.. мне бы твою уверенность и твои познания... А то я говорю что дешевле и для нас лучше 100-150 тыс потратить на полную оптимизацию нашей ДБФ базы, чем 500 тыс тратить на скуль, да ещё и новый гемор приобрести....

Программист говорит что нужно переходить на SQL, так как все большие конторы работают на SQL и что с ДБФ при таких объёмах уже никто не работает... И руководство соглашается с его доводами.
235 Ёпрст
 
11.04.12
14:57
(234) да какие проблемы ?
Пусть развернёт тебе скуль (хотя бы не лецинзионный), закинешь туда базу, заведешь юзверей на денек - посмотришь на реакцию и всё свалишь на программиста:)

пусть переписывает и оптимизирует
236 Ёпрст
 
11.04.12
14:59
(234) >>>> все большие конторы работают на SQL и что с ДБФ при таких объёмах уже никто не работает

ну это враньё, работают и еще как.
237 maxnn
 
11.04.12
15:01
(236) Ну и как мне это обосновать?
238 Ёпрст
 
11.04.12
15:02
(237) да никак, всё познается в сравнении.
Закинуть базу в скуль большого ума не надо.
А вот заставить её работать со скоростью, хотя бы сопоставимой с дбф - вот в этом и будет затык.
239 Ёпрст
 
11.04.12
15:04
+238 под "скоростью" я понимая время проведения документов, а не получение отчетов с ИБ.
Которые и в дбф варианте мгноввенно извлекаются при должном умении
240 opty
 
11.04.12
15:06
(232) Извиняй , но не очень то верится , 4-х гиг база , на очень не хилом железе индексится около5-6 мин , скорость индексации растет не линейно .

А ну у тебя как то и 10-гиг база за 10 мин реиндексировалась :)

Преимущество скуля никак не в скорости :)
241 opty
 
11.04.12
15:10
(237) Почитай форум , преимущества скуля и DBF обсуждались многократно .

Я например то же считаю что темк еще можно и нужно оставаться на DBF , хотя сам сторонник SQL . Вот будет за 50 активных пользователей , потребуется работа 24/7 , потребуется интеграция с например OLAP серверами , тогда скуль без вопросов .
242 FN
 
11.04.12
15:12
(240) ты у него лучше про дисковую подсистему спроси
например на ССД реиндексация ускоряется в несколько (до 10) раз по сравнению с зеркальным САТА-рейдом
243 Ёпрст
 
11.04.12
15:13
(241) ну у нас 60-70 активных юзверей, работа круглосуточно, за исключением воскресенья (хотя и в воскресенье теперь в ночну смену выходят)
и ничего, живём как то.
244 Ыщъ
 
11.04.12
15:16
Опять таки прямозапросечника в штат надо брать. А он ОстаТыщ запросит.
245 AquaMan
 
11.04.12
15:19
Вряд ли у вас скуль будет работать с приемлемой скоростью, доработки скорее всего писались на объектной модели, сервер столько запросов не потянет) Переходите на восьмерку)
246 Ёпрст
 
11.04.12
15:21
да -да..переходите на снеговика - там тормозов в разы больше.
+ нет никакого контроля в конфе..просто праздник какой то!
247 viktor_vv
 
11.04.12
15:23
Я как-то легкомысленно закинул одну ДБФ базу в скуль. Там еще и конфа какая-то левая и старая была. Больше одного дня не выдержали. При беглом анализе оказалось, что там переписывать дохрена и еще чуть-чуть.
248 G-Re
 
11.04.12
15:23
(234) Пригласи "программиста" в эту ветку, пусть аргументированно объяснит свою позицию не руководству, а простым специалистам.
249 Ыщъ
 
11.04.12
15:24
(247) Вот поэтому "спецов", безапелляционно заявляющих: "Только Скуль", пинком под зад.
250 FN
 
11.04.12
15:32
(243) ты про винты все же расскажи - что там на сервере стоит?
251 Ёпрст
 
11.04.12
15:35
(250) да ничего особенного .. немножко винтов в 10-ке.. хотя лучще всё же 0 ставить.
252 Torquader
 
11.04.12
15:56
А в прошлые года и периоды очень часто заглядывают ?
А то есть мнение, что прошлые данные можно хранить в другой базе, в которую, при необходимости, заглядывать из основной.
253 opty
 
11.04.12
16:11
(252) Свертку уже предлагали , но по каким то не очень понятным причинам , такой вариант не очень канает
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший