какая версия MS SQL лучше подходит для 1с 7.7 #396515

В нашей организации стоит 7.7 Производство+услуги+бухгалтерия ред 2.8 сетевая  на MS SQL 2000-конфигурация нетиповая и  не обновлялась с 2005 г. У наших партнёров стоит тоже пуб но на MS SQL 7 и у них производительность выше чем у нас. Мы хотим ставить MS SQL 2005, скажите пожалуста, даннай версия MS SQL  совместима с 1с 7.7 и изменится ли производительность базы?

совместима ... измениться

а поподробнее, в какую сторону изменится?

трудно угадать ... обычно в сторону улутшения изменяется...

ну у вас обоснования.....мне начальнику надо обосновывать почему ставить/не ставить 2005

Обычный подход. Поставить ворованную скуль 2005, проверить, если подойдет - купить лицуху.

вам надо объяснить как руководству обосновать покупку скулятины 2005(ее вы кстати официально уже не купите) ... или сказать, что случиться у вас...

Можно Express поставить...

у нас уже есть лицензционка

она давно куплена

ИМХО, зависит от сервера. Более современные версии скуля, более грамотно используют ресурсы более современных серверов. Если же вы планируете ставить 2005 вместо 2000, на сервер года эдак 2002, то может получится и замедление.

Если вас не стесняет, что 1сну придётся ломать, то почему бы и нет...

а вообще судя по сабжу... одним скулом вы не выкрутитесь... нужно комплексное решение, поэтому если сами в этих делах не бум-бум(сдается мне, что так и есть)... то лучше пригласите специалистов

Кстати, а вообще законно патчить dll для запуска 2005?

Последние исследования на мисте утверждают, что законно :-)

нет. Но это никто не проверяет. Т.к. на предприятии всегда есть более явные нарушения ГК4.

дежавю?

Вроде сейчас 1С прилагает лицензионное соглашение со стандартным пунктиком про декомпиляцию и т.п.? Если прилагает, тогда не законно.

>> У наших партнёров стоит тоже пуб но на MS SQL 7 и у них производительность выше чем у нас. Производительность пуб или SQL сервера?...

Покажи лицензию на 7.7 :-)

сейчас расскажу в чём это проявляются, ночью у нас запускается задание на восстановление границы последовательности у партнёра за ночь проводтся месяц, у нас только 15 дней

Может у них документов меньше?

И вообще, фотку!

у партнёра база даже больше чем у нас

просто зарегиться не смогла

этот глюк при переходе на 2005 (или наоборот, на более древнюю версию) - пропадет... это глюк чисто 2000 сервера

актуально

Тебе уже ответили.

нет не ответили т.е. если 2005 ставить, то его сломаный ставить ?

сломанную 1с, а не скл. Ибо 77 штатно не работает с 2005-м

тесты не пробовал? например заодно это поможет понять, что 90% совсем не в версии SQL

Нда, ахренительный показатель. А железо у вас абсолютно идентичное? А состав соофта, работающего на серваке одинаков? А еще ... а еще ... а еще ...

но восстановление последовательности - замедляется все-таки нехило... у нас проводило на 2000м полтора месяца за ночь, на 2005-м - весь период почти всегда

Кстати, давно бы уже надо было обратиться в 1С с просьбой объяснить ситуацию с 7.7+2005...

Ты чего как маленький? Выдавливание семерки любыми путями.

ты бы поиск заюзал... все уже давно было

Да ладно тебе, выдавливание.

Восстановление последовательности надо делать в монопольном режиме. Раза  в 3-4 быстрее получается.

+ и транкзации бить примерно по 100 документов, да еще много чего можно сделать полезного для увеличения скорости....

(39,40) замедление восстановления последовательности связано с неисправленным за 8 лет багом 2000 скуль сервера - на создание каждой последующей временной таблицы (и ее уничтожение) - уходит больше времени, чем на предыдущую... а 1с при временном расчете, запросах, отборах и пр. - эти временные таблицы усиленно использует...

по чему и надо транкзацию рубить по 100 документов :) и чистить свои переменные, я помню переписывал для ТиС а обработку востановления последовательности, прирост скорости у меня стал примерно в 2 раз причем НЕ В МОНОПОЛЬНОМ режиме, и пользователей почти не тормозило, эта обработка у меня вообще постоянно была запущена в фоне на сервере.

не связано.замедление и так будет...чтобы с 2000  сервером избежать замедления - нужно после каждой транзакции (или сотни документов и т.п.) - переподключать сессию к скулю... в 1с++ есть для этого функции... а транзакция 1сная - она прироста скорости в однопользовательском режиме не дает - проверено :Р

адин фиг транзакции не особо спасают, а вот реконнект реально рулит.

кстати про «пользователей почти не тормозило» - не верю... посмотри в профайлере, какие она блокировки накладывает - ни один документ ты не проведешь, элемент справочника (если вид справочника используется в транзакции) не запишешь и т.п... особенно, если пачки по 100 документов - явно больше минуты будут проводится

(0 )ага, вот моя тема

а самое интересное, если где-то в середине какой-то документ не проводится - и тогда вся транзакция накрывается...

у меня была пауза между транкзациями, а размер транкзации я подбирал по количеству строк в докементах таким образом, что-бы она ваполнялась примерно 30-40 сек. потом паузу 15 сек (между транкзациями), в среднем проведение доков у пользователей замедлялось на 10-15 сек. что вполне нормально для типового ТиС - а. Про реконект - спасибо, не знал

нет....  просто с данного документа проведение не идёт дальше

перепиши: не через количество строк/документов, а через _GetPerfomanceCounter - да и сами транзакции покороче (секунд по 15 как раз), а расстояние между ними - побольше - до 30 секунд (кстати, как правильно вставлять паузу без загрузки процессора - есть в КЗ) - и увидишь счастье на лицах пользователей... а еще лучше - автоматом ночью последовательность восстанавливать (у меня так сделано)

я это делал лет 8 назад :))) примерно в 2000 году, сейчас я-бы вообще по другому сделал-бы, ведь в 90% случаев отката последовательности - необоснованая!!! я-бы переделал штатную систему последовательности на более интелектуальный вариант.

кстати в эту-же тему идет и коректное проведение по партиям задним числом, я начинал делать, но уперся в одну технологическую нестыковку, а вообще сделать можно

сделать можно... но тогда нужно в каждой строке указывать партию, и выбирать при корректировке не больше, чем есть по этой партии минимум остатков от документа до ТА... или другую партию юзать, по которой есть достаточное количество _таких_ остатков

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

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

55 .... что-то вы не в ту степь пошли

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

РС.ReconnectNative; //реконнектимся воткни в обработку после проведения 50-100 доков, только перед этим закрой курсоры и удивишся.

+ только доки в тз лучше собрать и оттуда проводить потому как Док = СоздатьОбект("Документ"); надо будет перед реконнеком обнулять.

А про закрытие курсоров можно подробнее?

все переменные с выборками = "";

можно, только это для комплексной критично. 1 обнулить всё созданное как док в , ну кроме тз 2        глСпрВидыРасчетовБаза = ""; //закрываем курсор

19.03.09 07:00:03  Среднее вермя проведения дока:  0.63012522573196364605 сек. на комплексной стандартной (без изменения модуля проведения) ~ 400000 доков, с СКЛ 2000 кот. больше 2Г оперативки не ест.