Что делать.

Сконвертированная база из семерки. Чищу все лишнее.
Например при конвертации все доки являются регистраторами всех регистров.
Есть лишние доки которые просто удаляю объекты.

Если удаляю пару доков, то база уходит в реконструкцию на 10 часов.
В семерке такого нет.
Что занафиг?

>>>Сконвертированная база из семерки

извращенец

(1) маньяк

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

и итоги тоже - потом грохай в пофигураторе что угодно.

(1) я проект делаю путем конвертации семерочной базы.

Из нее перепрограммирую все целиком под восьмерку.

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

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

(0) делай реконструкцию раз в месяц ночью
заданием сервера

(0)
что такое "реконструируется" ?

(3) чистить нельзя. как раз смысл в том чтобы потом перенести все с движениями, накатить поверху доработанную с модулями. и люди продолжают работать без перепроведения базы.

(7) это он так реструктуризацию называет.

(9) ок. я конечно же подозревал.

>>>Есть лишние доки которые просто удаляю объекты.

Это же в пофигураторе делаешь, не так ли ?

Нафиг она вообще вся реконструируется если я удаляю пару доков которые регистров не касаются.

Мань, а Мань...
реструктуризуется, а не реконструируется...

ну и удали эти доки прямым запросом и движения регистров по ним + желательно или прибить итоги совсем, или отключить их..
а потом уже в пофигураторе прибьешь эти объекты.

Это ежели я правильно тебя понял, что ты там делаешь.

цука. все из за этих галок которые назначаются всем докам как регистраторам всех регистров....

(12) ссылки ищет, а их у тебя 30 гигов

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

(17) не, проблема в (16) - ищет ссылки во всех регистрах.. ну и пересчет их всех.

(18) еще и справочники. и все остальное. хотя они не трогаются. Я просто удалил несколько лишних объектов в доках и все. Реструктуризацию делает полностью. И справочников и документов и регистров.

(19) а не проще найти в бсп процедурку которая вычищает базу от бессылочного хлама и доработать ее до ума, чем самому копаться и чистить по 2-3 дока?
Хотя не помню, есть такая или нет, но по памяти она чуть ли не пол странички занимает в самописном варианте.

(20) ууууу это вообще насчет БСП у меня сейчас еще больше проблем.

Я в уже сконвертированную конфу в которой переписал все под восьмерку внедрил БСП
Так вот если я сверху накатываю свою базу с БСП так база вообще на сутки уходит в сон.

еще и валит мне разрушение базы на полях. уже задолбался вторые сутки.

(21) вопрос конечно глупый, но боюсь услышать страшный ответ:
файловый вариант?

Все на 83) Причем конвертатор 82 и 83 не работают.
Приходится сначала базу на 81 конвертировать конвертатором 77-8
Потом запускать в 83 - там конвертировать под 83
И только уже потом будет база конвертированная с которой я уже могу что то делать.

(23) на всех пробую.

(24) ты маньяк-извращенец

удалить на пустой конфе с загруженной .cf, перенести данные. иначе оно для каждого типа проверяет, нет ли в регистре случайно записей из удаленных типов регистраторов

ну дак ты бы с 6.0 ещё конвертировал... исходя из качества конвертации понятно что быстрей самому объектов накидать и логику, покрайней мере правильней

(27) вопрос глобальный - каким макаром перенести базу в пустую?
30 гиг.
Еще потом и проводить все придется.

У меня основная суть была именно перетянуть всю базу тк она с движениями доков. Доки не нужно будет перепроводить.

Фирма в режиме круглосуточной работы. Мне через 4 месяца надо будет все запускать так чтобы все выполнилось за пару часов.
Конвертация рабочей и накатка сверху  CF с модулями и формами для восьмерки.

(29) остатки переноси, будет у них 2 базы

данные перенести не легче?
пустую базу конвертируй, накатывай, потом данные перенесёшь

(31) нужна вся база.

используй 8.3

(32) Разработку я веду на первой конвертации которую сделал изначально.
Вот решил сейчас взять срез рабочей и накатить на нее то что сделал.

Каким образом перенести в пустую конфу 30 гиг данных с движениями всех доков - я хз.

(35) конвертация данных, выгрузка/загрузка XML, что хочешь еще...

Блин, дали уже совет...
Возьми cf, загрузи в пустую. Удали-почисти там метаданные, потом загрузи его обратно в рабочую. Реструктуризация будет, но один ращ

Постоянная реструктуризация происходит
1) на удалении ненужных доков.  которые пустышки по сути
2) галках регистрации регистров.
3) тут же еще вмешивается то что у меня на разработанной еще БСП втулена.

(36) ))))) смеешся чтоли??? Какая нафиг выгрузка загрузка 30 гиг базы.
XML сдохнет не родившись.

(37) так я на втором этапе накатываю CF выгруженный и модифицированный.

Жаль что не 100 и не 200, ты бы год переносил.

(40) Один раз сделай.

Ты остатки выгрузить не пробовал?

(37) нифига подобного! Объекты есть в той базе на которую накатывается. Они там не будут удалены если их нет в новом CF!
Ты ниразу обновления не делал?

(41) да там всего 2 года. Даже можно сказать год, тк за этот год контора разраслась в десяток раз.

(42) Включи мозг! В базе приемнике никаким образом не удялятся объекты сами по себе!

их только можно удалить РУКАМИ!

если такой объем и дефицит времени имхо только используя TSQL. Делал подобное: сначала написал прогу, генерирующую скрипт переноса, потом расположил обе базы на одном скуль-серваке и вперед. Сам перенос много времени не занимает, но написание проги по формированию скрипта скульного - это да, долго.

(43) мне пять раз одно и тоже писать что пять раз уже в теме написал? - задача перенести всю базу и начать работать в один день.

ЗЫ остатки я уже тоже переносил. с помощью КД - дохнет нафиг сразу на памяти. Один только справочник номенклатуры в 400 000 элементов на XML  в пару гиг выгружается и умирает на 24 часа.

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

(48) Хм. щаз посовещаюсь.

(50) ну и просвети? по ОЛЕ??? о дА! 30 гиг по оле))

"Они там не будут удалены если их нет в новом CF!" о_О

вообще странно: Маня - и взвалил на себя такой геморрой... почем подрядился на такое? ;-)

(52) я тебе уже сказал, юзай 8.3

еще и без движений доков.
Сконвертированная база как я писал выше - сохраняет все движения у всех доков по регистрам.
Мне просто нужно накатить сверху конфу с модулями, формами и БСП. и почистить хрень.

(55) я итак на 83. конфа под такси.

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

Сегодня не день Мани. Он слов не понимает вообще. Хотя и раньше не очень-то блистал.

(57) так там же фоновая реструктуризация. в чем тогда проблема?

(57) буржуйская чтоль?

(58) я уею с вас товарищи. Ты читал выше? ты хоть раз ДЕЛАЛ ОБНОВЛЕНИЯ?
ХРЕНЬ НЕ ЧИСТИТСЯ из базы приемника ни при каких обновлениях.
Джае в типовых они переименовывают их но удалить не могут.

(59) Я вижу кто не понимает. Каждые десять постов идет повтор какого то глупого совета.
2 человека в теме вообще с нулевым знанием процесса обновлений и удаления объектов. Не УДАЛЯТСЯ в приемнике объекты никогда никаким обновлением.

(0) Обратись в 1С - база мелкая а столько гемора, они такого не обещали,обещали что будет быстро

может, забить на реструктуризацию ?
Подмени табличку с конфой в скуле с базы-пустышки и усё..
Ну будут лишние поля в скуле - потом прибьешь.

(65) НЕЛЬЗЯ
Разработка ведется на пустышке.
При каждой конвертации из 77 в 8 - конвертация создает уникальные ID всех объектов.

(65) Это если знать структуру конфига. Как вариант - катит, конечно, но кто тебе покажет лишние поля?

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

Чем тебе лишние доки насолили? если мешают удали их еще на этапе 7.7.

(69) да фиг с ними. уже не трогаю. удалил. Сейчас пытаюсь уже сверху накапатить CF. Уходит в сон и каждые два часа вылет.

(67) сам скуль и покажет - будут 2 базы в скуле.. пустышка и рабочая, имена табличек будут одинаковые, только колонок и самих табличек в одной базе будет меньше..Их тем же скулем и грохнуть/реструктуризировать.

(63) очевидно что вы путаетесь в терминах.
если в конфигураторе удалить объект, или например загрузить кф с удаленным объектом, то конечно он не удалится вбд.
но если потом выполнить ОБНОВЛЕНИЕ, например по ф7, то удалится как миленький.
о чем тебе и сказали в (37)

(68) Может с проведением замутить?
Составь список проведенный в 7.7 документов
Отмени проведение
Перенесе в 8
В 8 настраивай регистраторы
и потом перепроводи

с 30 гиг в 53 сейчас превратилась и оборвалась нафиг.

как ни крути а штатно 30 гигов за 2 часа не перелопатить.

(73) боюсь что перепроводка базы с 2000 доков в день это месяц.

(74)может в симпл перевести и журнал отключить?

(76) Что то я не понимаю, ты в 8 выгружаешь доки и не проводишь?

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

(39)(52) и что?

(80) то что я из этой УТ в БП один месяц 4 часа перегружаю движения за месяц. а ты всю базу хочешь)

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

(82) я точно уверен что метод выгрузки загрузки будет дольше чем руструктуризация.
Пока чт оу меня еще проблема чт оя ниразу не смог выполнить ее до конца из за вылета ошибок.

Я думаю все виной добавленная БСП в разработанный CF

а без нее тоже никак((( палка о двух концах. Короче продолжаю мучать все свяческими способами. Будет результат отпишусь.

походу придется БСП круто резать. оставлять только базовое.

с чего уверенность что БСП виновато? виновата реструктуризация таблиц с данными (много много где), или это вызвало БСП?

(87) ей в том числе.
При удалении или добавлении любого объекта докуента (а в БСП они есть добавленные) уходит в реструктуризацию.
У меня двойная ситуация.
И БСП и свои.

(82) скорее еще проще.. alter table + drop table
^)

Сама тупость этого процесса что начинает пересчитывать всю базу даже если эти доки никаким боком в регистрах не учавствовали.

(88) реструктуризация идёт если затрагиваются другие объекты. Если есть тип ДокументЛюбаяСсылка - то будет реструктуризация того объекта, да. Иначе не будет

(89) :))))) самый просто видимо пройтись копи пастом) и вставить все формы и модули)))

(90) хз, может у тебя есть индексируемые поля с типом ЛюбаяСсылка.

(93) сейчас гляну.

(93) даже если так то должна пересчитывать только этот регистр. а пересчитывает все.

(86) Это уже палка о 3 концах, мне как то нужно было пару систем, в итоге опять же пол БСП к нему присосалось)

3 регистра в которых измерение с типом Документ.
Взаиморасчеты, партии, товары отданные.
Галок по индексиции у них не включено.

(95) Ты знаешь каким образом храняться составные типы?
А вообще что то явно с базой не так - это тебе не выгрузки из экселя.

(97) да пофиг на индексацию, всё равно структура таблицы изменится

Самый большой регистр Статусы заказов клиентов.
И он уходит в любых случаях в реструктуризацию. У него только заказ клиента с типом.

(98) ну да. Она всего навсего 30 гиг. А я накатываю на нее конфу с БСП в которой присобачено половина метаданных новых.

(0) была похожая проблема в УПП (120 Гб). Зависала на регистрах сведений с текстовыми полями (10 тыс. записей).
После очистки регистра все заработало.

(101) У меня было такое как то раз, откатился до начального состояния более аккуратно все накатил и пошл нормально. Там у тебя случайно хранилища нет?

(99) этот регистр можешь выгрузить-загрузить xml-кой?
суть - здоровые регистры выгрузи, реструктуризируй и загрузи в зад

И замените слово реконструируется - реструктуризируеца в заголовке, а то глаза режет.

(104) 30 гигов это все равно не 10 часов, дело там явно не только в данных регистров. У меня примерно на таком же объеме регистры бухгалтерии и то быстрее реструктуризируются - где то пол часа не больше.

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

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

данных - только регистров, естественно. на все про все - максимум час.

(108) структуры таблиц же наверняка разные будут, надо смотреть будет каждую различающююся, чтоб понять как перенести

специально для мани - продам за 5000 обработку помошник сокращения типов

(110) сфига? я ж говорю, скулем перед реструктуризацией копию делаем. при усечении типов регистратора сами поля не меняются (по крайней мере я не замечал)

(112) Как же они не поменяются, когда для хранения каждого из типа составных данных отводиться отдельное поле.

На вот, решение всех проблем.. за даром:

declare @name nvarchar(128), @Rows int
declare Names cursor static for
select
    table_name
from
    INFORMATION_SCHEMA.TABLES
where
    table_catalog = DB_NAME()
    and table_name != 'dtproperties'
open Names
SET @Rows = @@Cursor_Rows

WHILE @Rows > 0
begin
     FETCH Names Into @name
    SET @Rows = @Rows - 1
    declare @qt nvarchar(128)
   set @qt = N'drop table +'+@name
    exec sp_executesql @qt
end
close Names
deallocate Names
© ADirks

(113) если только ссылочные - то нет, всего 3 колонки, не зависимо от того, сколько там разных ссылок может быть

(114) злой

вычищает с базы всё лишнее, в разы ускоряет работу базы.

(16) наеборот, добрый
:)

(114) :)

(114)

Есть только одна проблема. Такая малюсенькая.
У меня есть  СF который я получил один раз из конвертации.

Теперь я делаю новую конвертацию рабочей базы с данными и меня - хренак и все новые внутренние идентификаторы, соответственно и таблицы тоже.
Это уже не две одинаковые базы.

Например я уже не могу конфу обновить методом Загрузить новую конфигурацию - у меня полностью удаляются и создаются заново все объекты. И залить я сейчас могу только объединением.

(122) -> (112)

(121) блин..
Средствами скуля имеещь клон базы один в один, в нём чистишь всё скулем, делаешь реструктуризацию свою, имеешь рабочий cf-ник..
Далее как хочешь - хочешь 1 раз накати на рабочую конфу и жди, хочешь, dts-ом перенеси в клон с рабочей, хочешь, наеборот, в рабочей соглано клону отрежь лишнее.

Кажется я прогнал. тк как не попробовал сделать так:

1) конвертирую базу. У нее новые ID
2) теперь я из этой базы выгружу в пустую CF
3) там на пустой накачу свою.
4) выгружу из этой
5) загружу ее в базы с данными.
Емае этож вариант. Внутренние останутся от родного CF
Может даже получится тогда сделать не объединением а замещением.

дел.. на пол часа на всё..

(123)(124) он имеет ввиду что после реструктуризации AccRg2305 вдруг станет AccRg666

(127) это как ?
:)

(127) вот вот. а оно так и происходит.
Обработка конвертации базы 77-8 создает базу каждый раз со своими новыми идентификаторами таблиц.

(128) это я так понял его пост (122).
при удалении-добавлении объектов номера таблиц в скуле могут сместится жеж

(128) а вот так. если в конфигураторе делать Загрузить измененную конфигурацию6 а не Объединить, сравнить - она выдает удаление всех объектом и создание новых - этих же самых.

(130) старые объекты так и будут со своими ид.

что в оригинальной базе, что в кастрированном клоне.

(131) я про скуль, что в конфигураторе мне пофиг) Я не знаю будет ли сей эффект после реструктуризации

(134) и в скуле аналогично

(132) если бы так было то конфигуратор бы не выдавал удаление всех и создание новых.

(133) насколько помню - там сквозная нумерация, если удалить из "серидины" - остальные дальше сменят ид, или я туплю?

(137) конечно нет, у тебя же соответствие cf-ки всем табличкам в скуле..

(133) В оригинальной базе каждый день еще один прог сидит колбасит новые объекты. Никто работу в ней не отменял.

и ..примитив на генерацию нового ид для метаданных - всё время на увеличение..

Я их сейчас добавляю к своей. Уже было два новых документа. Удаляли в семерке и чистили тоже много чего. Регистр добавился. Я это уже руками вношу в восьмерку.

(139) ты переезд на месяц растягивать собрался что ле ?
Всё делается за раз один раз.
Усё.
:)

(142) 4 месяца. подготовки. 1 день запуска.

нам еще полбазы надо написать обработок, отчетов. и прочего.
Я пока что сделал документы, формы и их модули.
И для тестовой гоняю рабочую базу.
Сейчас роботов еще дописываем подключать будем и так далее. Работы еще еперный балет.

(144) скайнет там не изобретите

Даже пустую CF сейчас не могу поверху залить свой.
пипец... уже просто на пустой базе пробую.


Сыпет
Таблица поле Fld2891 не содержится в разделе FROM
Сейчас буду искать что за хрень

А я сразу сказал, что дело не в данных.

+(146)
1) из конвертированной выгрузил конфигурацию
2) пытаюсь на пустой базе объединить со своей, чтобы потом этот выгрузить и на рабочую подгрузить.

а я думал, Евгений мегаспец и всё умеет

(149) Он только по экселю. Ну еще вроде как продажник неплохой.

Методом тыка объединение прошло с установкой совместимости.

"Самый большой регистр Статусы заказов клиентов."
зачем хранить устаревшие статусы?

(152) год минимум. специфика бизнеса.

(144) посоветуй им позвать специалиста

(153) зачем? вот скажем по отгруженным  уже. какова цель?

(155) отгруженным нет. Но статус заказа закрывается полностью только есл и все позиции заказа выполнены. Даже статус отгружено это итог в регистре.
Пока не будет сделано закрытие. которое уже отменит и статус отгружено.
Для целостности информации на сайте. И работе с клиентами.
Плюс есть заказы которые могут быть актуальными месяцами.

(154) вот так посоветую и все вопросы сразу решаться. от простого совета вдруг всем станет легче. Сразу спецы по 83 набегут!! - веть таких сейчас хоть лопатой греби.

цука. пошла реструктуризация на рабочей базе без вылетов.
Все получилось только при смене методом тыка редима совместимости.
За 15 минут обработало 380 тысяч элементов справочника единиц.

С последнего помента ничего не пробовал.
С серваком завозились. Сейчас запустил снова. Жду. Уже 7 часов белый экран.

(0) Все не читал, но напрашивается перенос через XML
Потихоньку переноси документы. Помесячно, до закрытого периода (где по сути не могут поменять документы) включишь УРБД 7шное и дальше переноси:
Типа - все измененные от даты закрытой по месяц переноса + месяц.
Ну и в конце у тебя получится 2 идентичные базы. В последний момент перенесешь только все измененные и заставишь юзеров уже в новой все делать.

В принципе сейчас примерно тем же занимаюсь. ТОлько у меня 2 сторонний обмен.

(160) не тянет XML.  Мы ежемесячно из торговли в бух выгружает данные. занимает все порядка 6 часов. Только за 1 месяц.
Это еще и провести доки.
У нас оменклатура огромная.

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

(162) Ну и кули неделя? У тебя же юзеры всю эту неделю будут в старой 7ке работать. А как до конца догрузиш моментом их на 8ку перекинешь.

Ну и сравнил - самописку и бухию. У тебя там поди 2 регистра и 3 справочника. Быстрее будет делать

Тем более сразу проводить и нет необходимости. Загружаеш в 8ку со статусом записано, но не проводиш. Это еще быстрее. Потом, ближе к концу все скопом проведеш

Ну и еще плюс. Никто же тебя руками не заставляет помесячно  переносить. Там практически пару строк кода + правила+ обработка стандартная 1Совская по переносу из КД.

(19)специалиста пригласить?

(167) Точно. За полтос легко напишу.

(0)вообще подумать что именно делается столько времени и почему не предлагать?

(162) Советы толковые уже давали, просто ты их не видишь.

(164) вот именно! что ты сравнил самописку в которой просто шизец взаимосвязей и всего остального. И бухию в которую только номенклатуру, количество, цену, сумму достаточно передать.

(169) давно изместно что и оно единственное - реструктуризация и пересчет регистров.  Хотя конкретно они вообще никак в накатываем конфигурации не изменены.

В новом CF добавлена БСП. С ее справочниками, один док взаимодействий и куча регистров сведений.
Я когда БСП внедрял на первой сконвпертированной базе - она только в полную реструктуризацию - пересчеты регистров ушла.

Хотя в этой БСП вообще объекты никаким боком и ни одним местом к регистрам нашим не лежат.

Это видимо способность движка - уходить в реструктуризацию при каждом чихе и вообще при невзаимосвязанных НИКАК между собой объектах.

Короче говоря в 1С считают что надо все регистры пересчитывать при любом чихе.

(170) они не подходят. Не подходит выгрузка и загрузка через XML. И точка! не нужно это даже советовать.

в 1С надо писать письмо. Это недоработка платформы.

что за ужасы по понедельникам?

(62) Конфигурация - Сравнить, объединить с конфигурацией из файла - Настройка - Разрешить удаление объектов основной конфигурации

ХЗ как там в 8.3, но в 8.2 было так.

В типовых удаляемые реквизиты переименовывают чтобы дать возможность перенести из них данные.

(177) в 83 тоже самое. наследование тоже не помогает.

Короче без реструкрутизации никак. А я думал 10 минут и все будет готово.

(178) а галки ставил на объектах которые надо удалять?

(114)что оно делает?

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

(114) добрый ты нынче что то )

(0) если по теме, то как минимум на скуле модель восстановления - Simple. Потом архив и шринкнуть базу. Уже веселее на порядок будет. Ну и с параметрами роста файлов базы и лога поиграться, сделать их чуть побольше, чем стандартные 1Мб и 10 процентов.

(114)что  делает?

(114) Сначала обрадовался. Думаю во классно, есть классное решение которого я не знаю. Даже приятелю с проблемами производительности хотел послать. А потом вчитался в код.

(185) А ты поищи "DROP TABLE"

А Ёпрст весельчак...

(188) Я бы удалил такую шутку. А то кто-нибудь может и повестись.

(189) Да ладно... Было уже - как изменить формат файла...

(187)это понятно, только конфа в одной таблице лежит э этот код что прибивает?

(185) избавляет от торможения . База просто летает!

(191) Если понятно то какие вопросы.
(192) Настырный

(191) вы можете попробовать на тестовой базе :-)

ыыыыы
1)сконвертировать базу из 77 в 8
2)выгрузить конфу из восьмерки, сделать пустую базу, загрузить конфу
3)рихтовать пустую конфу как надо
4)универсальной выгрузкой-загрузкой выгрузить данные из сконвертированной базы в рихтованную

профит!

(195)
выгрузить-загрузить 30 гигабайт ?

(195) всему бывает предел, а предел возможностей XML по выгрузке-загрузке - это гораздо меньше 30-ти гигов.

(196), (197) для вас обоих сюрприз что грузить необязательно в файлик?

+(198) или что грузить в тот же файлик не обязательно всю базу сразу?

(199) расскажи ка лучше, о учитель, из опыта своего: базы какого размера ты так перегонял, а главное - сколько у тебя это времени заняло?

(200) "расскажи ка лучше, о учитель"
а не пойти ли вам в сад?

А вот интересно. Можно ли завязать на уровне SQL две разные базы. То есть написать программу которая будет прямым запросом выбирать данные из одной БД и засовывать в другую.

(201) ну раз сказать Вам по существу нечего - стоило бы наверное промолчать. Прислушайтесь хотя бы к ТС относительно использования XML для решения этой задачи.

(203) ты сам то читал?
ну хотябы (50)? и что там до него?

может прежде чем выпендриваться, подумаешь?

(204) а ты (161) внимательно читал?

(205) да читал. Мальчик дурачок, МПХ умудрился сломать. И что?

(206) я конечно знал, что есть такие одинэсники, которые всех вокруг считают идиотами, но думал, что до 38-ми годов такое точно проходит. ТС по крайней мере попробовал это делать, а Ваши выводы сплошь умозрительны.

"ТС по крайней мере попробовал это делать, а Ваши выводы сплошь умозрительны"

бугага

(202)
легко. читайте про триггеры и view

на уровне субд ms sql можно даже "бесшовно" организовать работу в 1с77 и 1с8 в рамках одной базы. естественно с сопоставимыми сущностями

spt_fallback_db
spt_fallback_dev
spt_fallback_usg
MSreplication_options
spt_values
spt_monitor

select
    table_name
from
    INFORMATION_SCHEMA.TABLES
where
    table_catalog = DB_NAME()
    and table_name != 'dtproperties'

и что?

(210) да чистит тот код все в базе вообще. Выносится как сама конфа, так и данные.

вот мне братья по разуму ))) посоветовали )))

declare @q nvarchar(max) = N'';

select @q += N'drop table ' + quotename(t.name) + N'; '
from sys.tables t
where t.name != N'dtproperties'

exec(@q);

говорят что проще дропнуть

(212) еще быстрее скуль вынести тогда уж.

Пипец. Что за ....
Восьмерка при каждом чихе реструктуризирует всю базу, все объекты.
Просто в сконвертированной базе взял удалил неиспользуемый док - реструктуризация всей базы, всех объектов.

(209) Поучился бы с удовольствием

(215)msdn
(214)"всю базу, все объекты" - дурь энергетиками запиваете?

(214) База то у тебя на твердотельнике? Если нет, то ты и в правду маньяк.

(214)
со времен 8.1. реструктуризировались отдельно объекты
и только бух подсистема могла реструктуризировать доки (исправили).

в 8.2 реструктуризация проходит только у измененных объектов
8.3 - не знаю

(217) SQL, рейд на SSD

(129)ну так что же показывают мониторы производительности скульного и виндового серверов с базой?

Все пилять я победил ее.

Короче пилять ни в коем случае не юзайте 83, не знаю шо с ней но я смогу базу нормлаьно обновить только в режиме 8.2
И всего за пару часов.

(222) а разве есть конвертор из семерки в 8.3?

(223) не работает. 82 тоже не работает.
Несколько жтапов.
1) конвертация самой базы 81
2) запуск ее  и переконвертация в 82
3) далее режим 82 и в режиме 82 обновление конфы

(224) Неужели это сработало? Да еще и быстрее 10-ти часов?

(174)Я же говорю не слышишь, читай внимательней.

(222) монстр. Я всегда говорил и буду говорить - Маня горы свернет со своей энергией ). Хотя, смысл всех этих извращений, мне непонятен.

(225) быстрее чем 2 часа. Думаю даже еще быстрее. тк я даже и не засек. Увидел только что бах и готово.

Буду пробовать еще раз сконвертировать базу и накатить. Но уже через недельку.

Вот такие вот грабли с совместимостями.

за 1 час 20 минут в журнале.