<?php // Полная загрузка сервисных книжек, создан 2025-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
А вообще у нас ещё много разных интересных технологий 😉
:-))))
Жопа. У вас остаток товара в справочнике хранится?:)
Редкостный бред…
Не понятно: зачем выгружать и загружать документы, вводятся ли начальные остатки? Маловероятно, что после таких манипуляций сходятся остатки.
Автор поработайте над статьей, понять из написаного что либо сложно.
(2)
Остатки как и у всех хранятся в регистре.
Поэтому мы и выгружаем их на вечер ДатаОбрезания-1, а затем, в уже пустую базу, загружаем их в ту же дату документом «ВводНачальныхОстатков».
После них уже загружаем оставленный период документов.
(3)
Про бред не понял 🙁
Была задача без участия программиста выполнить в автоматическом режиме обрезание БД — задача решена…
Основная сложность была выполнить последовательность неких действий (которые я раньше делал вручную) и чтобы 1С, запущенная из BAT-ничка в пакетном режиме, понимала, что и когда ей делать надо…
(4)
В базе магазина продажи регистрируются расходными накладными. По 200 — 800 документов в день. Через год — полтора документов становится настолько много, что идут реальные подвисания как при создании нового документа, так и при его записи и проведения.
Обрезать «под ноль» — нельзя, так как в магазины периодически повторно перевыгружаются скорректированные документы закупа, корректирующие остатки.
Поэтому оставляем в магазине все документы за 1-2 месяца. Остальное прибиваем.
Выполнять удаление документов за отбрасываемый период в среде 1С, как это делается в стандартной — ооооооооооочень долго.
Поэтому:
Выгружаем остатки на начало оставляемого периода.
Выгружаем все документы за оставляемый период.
Удаляем физически все DBF-ки (кроме справочников) — очень быстро 😉
В чистую базу грузим остатки на начало периода и все документы в нём.
Остатки сходятся копеечка в копеечку. Что и подтверждается сравнением отчётов по остаткам товаров по входным ценам сделанным ДО и ПОСЛЕ обрезания.
А можно посмотреть болванки загрузки/выгрузки? У нас тоже конфигурация самописная, писали свои обработки, но всегда интересно посмотреть как у других.
А вообще идея замечательная, у самих почти десять объектов, обрезаем раз в несколько лет, но от этого не легче — делали всегда вручную, по бумажке :). Попробуем внедрить у себя.
(8)
Вот, первый комментарий по теме 🙂
Спасибо за поддержку 😉
У нас более 130 магазинов и сеть продолжает расти.
По жизни замечено, что при достижении размера *.dbf + *.cdx > 500 Мб — начинается вешалка. А если в магазине (у нас небольшие алкомаркеты) несколько касс, то они вообще конкретно мешают друг другу.
Да, делал обрезание вручную — ручное копирование, удаление *.cdx? куча выгрузок (всё было по отдельности : цены, остатки, документы и прочее), аналогично загрузки. Обрезание шло в одном магазине 40 — 50 мин (магазин стоял).
Когда сделал единую выгрузку (объединив все обработки в одну) и загрузку — стало 20-25 минут, но ручной труд остался.
Сейчас, грубо, управляющий запускает bat-ничек и курить 10-15 минут — всё!
Выгрузку/загрузку сейчас положу 😉
(3) Никакой ни бред! Подобная проблема у меня была с аптеками. И тоже периодически занимался «обрезанием» по тому же принципу. Идея «правильная». Пока не смотрел, но заранее спасибо.Да, про (8) не забудь.
Вот ссылочка
«Принципы выполнения Выгрузки / Загрузки данных при обрезании БД удаленного магазина»
Кстати «плюсики» можно и там ставить :-))))))
Если есть какие вопросы — пишите 😉
(9): По жизни замечено, что при достижении размера *.dbf + *.cdx > 500 Мб — начинается вешалка. А если в магазине (у нас небольшие алкомаркеты) несколько касс, то они вообще конкретно мешают друг другу.
Т.е. вешалка начинается при 500 метрах на фактически 1 рабочем месте, активно вводящем документы?
Сурово у вас конфа написана, ничего не скажешь…
По теме — идея интересная, такого способа (физически вынося неугодные таблицы) еще не видел…
Чем определяете имена таблиц?
Ручками парсите .dd файл или, скажем, через 1С++?
Данные документов выгружаете/загружаете через «ЗначениеИзСтроки()/ЗначениеВСтроку()»
(14) «Данные документов выгружаете/загружаете через «ЗначениеИзСтроки()/ЗначениеВСтроку()»»
это был вопрос 🙂
И еще вопрос — чем не подошел классический метод:
обработка, которая копирует необходимую периодику введенную документами; создает документы вноса остатков, помечает на удаление ненужные документы и т.д.?..
(14)
>Сурово у вас конфа написана, ничего не скажешь…
:-))))))
Самая любимая конфа :-). Писанная с «нуля» и максимально облегченная
НО, факты есть факты.
500 метров при огромной куче маленьких документов — это примерно размер
1SCRDOC.DBF под 100 метров, заголовочной части расх.накл — под 150 Мб, табличной части расх.накл — за 50 Мб — остальное маленькое.
И когда касса пытается под DBF-ом таскать подобные объемы для создать/записать /провести, а сервак — это обычный ПК — реально тормоза…
Специфика, блин.
А когда 2 кассы — вообще пипец. Они вместе(почти) нажимают «Провести» и всё — оба компа надолго задумываются, висят несколько минут — потом вываливаются из 1С из-за блокировок.
В лучшем случае одна касса остается в программе.
Лично наблюдал. После этого и решили резать.
В офисе базы (тоже самописные и гораздо более сложной структуры) более сбалансированные получаются (много мелких документов одного магазина за один день сливаем в один большой документ).
Так что на базах 2-3 Гига работают по 20 — 40 человек.
А нынче вот на SQL перешли. Хоть объем и раздулся, но всё равно веселее стало 😉
(14)
>идея интересная, такого способа (физически вынося неугодные таблицы) еще не видел…
Когда только пришёл в эту компанию (уж лет 8 как), всё так и было как в описанном вами в (16) «классическом методе».
Это после закрытия бокса с компьютером на рынке (раньше так было 🙂 )
выдирали из него винт, цепляли в офисе на крутую банку и … вперёд!
Не помню сколько там данных было, но если за ночь обрежется — зашибись 😉
Очень долго удаляются документы. А если большой период, то тормаза в геометрической прогрессии. Типа 1 месяц — 20 мин, 2-й — 50, 3-й 1,5 — часа и так далее. Чего-то там в 1С не круто реализовано.
А тут знакомый мастер подсказал — не парься : выгрузил, прибил *.dbf, загрузил. Да, нужно поработать — выгрузки загрузки написать…
НО, итог, 20 минут и база обрезана!
(14)
>Чем определяете имена таблиц?
Всё просто (это в BAT-нике):
rem — удаление всего кроме справочников
del /Q Путь*.cdx Путьdh*.dbf Путьdt*.dbf
del /Q Путь
a*.dbf Путь
g*.dbf Путь1sblob.dbf
del /Q Путь1scrdoc.dbf Путь1sdnlock.dbf Путь1sjourn.dbf
del /Q Путь1SCONST.dbf ПутьSYSLOG*.*
Можно и со справочниками побаловаться, если они распухли и в таком виде не нужны…
(15)
>»Данные документов выгружаете/загружаете через «ЗначениеИзСтроки()/ЗначениеВСтроку()»»
Нет знаете ли, как-то так исторически сложилось, что всё ручками, каждый реквизит в отдельное поле.
Знаю — не универсально. 🙁
Может когда и через метаданные напишем, но коль это уже скока лет живёт, добавить 1-2 новых реквизита — гораздо проще 🙂
P.S.
«Принципы выполнения Выгрузки / Загрузки данных при обрезании БД удаленного магазина»Кстати «плюсики» можно и там ставить :-))))))
Извините предыдущая ссылка чёт не работала, эта вот вроде правильная:
Жесть…
База в 500 метров вместе с cdx — это вообще оооооочччченнннь ммаааало, чтоб её резать.
А длинные строки как, которые в блобе валяются ?
Свёртка + прибитие файлов — вообще мегабоян..
Резать такую маленькую базу не в конце года — вообще моветон.
Книжки покупок/продаж вообще не ведёте?
Взаиморасчеты с клиентосами/поставщиками — тоже ?
+22 Посмотрел Выгрузка_Загрузка … тихий ужас.
(22)
В 17 посте уже рассказал что и почему надо резать, привел размеры dbf-ок которые по сети тягаются туда — сюда…
Там где документов мало : 100-200 в день (наши строительные супермаркеты),
нормально доживают и работают и при 1-1,5 Гигах, то есть там приведённые выше размеры активно юзающихся dbf-ок достигаются при 1-1,5 Гигах общего размера базы!
Если нет подобного личного опыта — лучше не комментировать.
Я это не из пальца высосал, а лично наблюдал.
От длинных строк вообще отказались, поэтому блоб пуст.
Открою секрет — длинные строки = страшные тормоза — бегите от них.
Если, к примеру, элементы справочника номенклатура имеют длинную строку (типа описание), то при бегании вверх-вниз по форме списка справочника — страшное замедление. ДАЖЕ если их и не выводим на экран.
В 1С длинные строки реализованы через ж…
(24)
«Лично он наблюдал» ..ппц.
Детсад.
(22)
>Свёртка + прибитие файлов — вообще мегабоян..
Вот это я не понял — все нормальные программисты, делают новые чистые базы, ну или обрезают, через выгрузку(если надо) / удаление dbf / загрузку(если надо) — очень быстро…
>Резать такую маленькую базу не в конце года — вообще моветон.
>Книжки покупок/продаж вообще не ведёте?
>Взаиморасчеты с клиентосами/поставщиками — тоже ?
Замечу, это база магазина (она только для торговли), когда достигает нужного размера или тормоза начинается — тогда и режем…
Вся информация с магазинов стекается в сводную базу в офисе.
Тут и ведём всякие долги и прочее-прочее.
СВОДНУЮ базу режем только с Нового года (если нужно)
Сейчас сводная на SQL превышает в размере 10 Гиг.
В ней активно работают до 20-30 человек — всё путем 😉
В общем повторюсь — своя специфика, кто её не имеет — тот не поймет.
+25 на сегодняшний день в одной базе *.DBF 10,9 Гб
размер самой большой дбф-ки 951 метр …
база с середины 2008 года..
+27 активных юзверей — 60-70…и всё летает.
(26) У вас в базе — 1 регистр, который ВЫ запросом выгружаете… дальше собственно, разговор можно закрывать…
мини склад млин..
+29 Причем, выгружаете весьма экзотическим способом…
(25)
Не хочешь не верь
(31) Верить чему ?
Что базу , в !!! 500 !!! метров это вместе с CDX, т.е реально она 100-200 метров нужно резать? И притом, что для учета там всего 1 (ОДИН) регистр ?
Конечно верю!
Свёртка базы путём прибития DBF- ок моветон. В данной статье не учтены все моменты. Подходит она, для оооочень специфических баз. Ибо прибивается вся аналитика вообще за прошлые периоды.
(27)(28)
Везёт 😉
У нас в магазинах в качестве серваков стоят Интел коре дуо 1,8,
да и винты обычные — может в этом дело?
>Посмотрел Выгрузка_Загрузка … тихий ужас
>Причем, выгружаете весьма экзотическим способом…
А чего не так?
(34) Да всё..
🙂
Выгружать Запросом — моветон, когда есть ВыгрузитьИтоги…
Скидывать всё в dbf, используя XBase … тоже
Загружать потом обратно, привязываяс к коду справочника — тоже…
Ну и т.д.
(32)
Какие-то пропорции неправильные…
Вот в реально обрезанной базе у нас такие пропорции:
CDX- 168М, DBF-433М
И потом цифру 500 мы для себя выбрали — для профилактики
На самом деле они работают и при больших размерах
Самые-то коллизии начинаются – если 2 и более касс стоят, вот когда они пытаются одновременно юзать по сети
1SCRDOC.DBF под 100 метров, dbf заголовочной части расх.накл — под 150 Мб
Вот тогда пипец – это собственно я и наблюдал…
Если уж так хочется резать, путём прибития DBF, то хотя бы так:
del -Y *.cdx
del -Y 1sjourn.dbf
del -Y dt*.*
del -Y dh*.*
del -Y ra*.*
del -Y rg*.*
del -Y 1SACCS.DBF
del -Y 1SBKTTL.DBF
del -Y 1SBKTTLC.DBF
del -Y 1SENTRY.DBF
del -Y 1SOPER.DBF
del -Y cj*.*
Далее ТиИ + галка очищать ссылки, удалять данные объектов.
Останется база токма со справочниками.. без лишних ссылок на объекты..
Потом думать о периодике и прочей муре.
+37 Но один хрен, если ведётся книга покупок/продаж — так не делают…
Если нужна аналитика в партиях (для тис, к примеру) тоже…
если нужна аналитика по КредДокументу — тоже..
и т.д.
(35)
Да ладно, работает же 😉
Всё как-то исторически сложилось 🙂
А что касается «ВыгрузитьИтоги» — задумаюсь, как-то до сих пор не использовали…
Тем более наша ВыгрузкаОстатков через запрос идёт около 10 секунд. стоит ли париться?
>Скидывать всё в dbf, используя XBase — тоже моветон
а как можно лучше? подскажите…
>Загружать потом обратно, привязываяс к коду справочника — тоже…
а как же по другому?
(37)
del -Y 1SACCS.DBF
del -Y 1SBKTTL.DBF
del -Y 1SBKTTLC.DBF
del -Y 1SENTRY.DBF
del -Y 1SOPER.DBF
del -Y cj*.*
у нас в торговле этого нет
Нету у нас? самописное всё с «нуля»
> книга покупок/продаж
> аналитика в партиях
> аналитика по КредДокументу
И вообще, я тут собственно с другого начал — с BAT-ника
Выгрузки/загрузки — не презентовал, не хвалюсь я ими — самые рядовые
Просто люди попросили глянуть для примера как у нас — вот и выложил
(39) А ты сравни метод ВыгрузитьИтоги с установленым фильтрами со своим запросом…
ЗначениеВСтрокуВнутр/ЗначениеИзСтрокиВнутр — поимеешь сразу сам объект, и не надо ничего искать…это самое простое.
А справочники ни с регистрами ни с документами никак не связаны — не трогаем их и всё.
Если просто убить регистры и документы и почистить периодику — то просто получим чистую базу для нового магазина.
(42)
Спасибо, вот это интересно.
Проста так обмены ещё до меня были написаны и я особо не углублялся…
>ЗначениеВСтрокуВнутр/ЗначениеИзСтрокиВнутр — поимеешь сразу сам объект, и не надо ничего искать
Не очень догнал
Сейчас, при загрузки документа, я для заполнения у него реквизита «склад», например, ищу по переданному коду склада в справочнике складов и подставляю найденный элемент.
А как будет по новому?
Можно кусок кода для примера?
(45) а так не будешь искать, а сдлаешь Склад = ЗначениеИЗСтрокиВнутр(ранее сохраненная строка, как ЗначениеВСтрокуВнутр(Склад));
Попробую
(46)
Кстати, экспериментальным путем получено, что при использовании
ЗначениеВСтрокуВнутр(Объект) длинна возвращаемой строки 44 символа или бывает больше?
Сколько нужно в Dbf-ке на длину поля резервировать?
(48) Вообще-то DBF для обмена данными — прошлый век, я юзаю XML и всем советую
(49) Помниться, XML-парсер из v7plus.dll в чем-то был нестабилен…
А с ДБФ — все просто и примитивно.
К тому же — есть индексация.
(50) Хм… что-то я не наблюдал никакой нестабильности
Примитивность ДБФ накладывает ограничения и неудобства
(49)
А в чем выигрыш?
В объеме выгрузки или в скорости?
С XML-лем немного баловался когда делал выгрузку данных из 1С на платёжный терминал…
Там структура передаётся построчно и, субъективно по мне, мене визуально читабельная, чем четко определенные поля DBF.
(42) (46)
Побаловался я с ЗначениеВСтрокуВнутр/ ЗначениеИзСтрокиВнутр
И понял, почему мои предшественники отказались от использования данной технологии…
1. Скорость загрузки/выгрузки никаким образом не меняется ни в какую сторону,
2. Объем выгрузки только возрастает в разы, так как передаем не код – 4-5 цифр, а строку 50 символов – а это возрастание трафика…
3. Код выгрузки загрузки выглядит более компактно, НО
4. ПОЛУЧАЕТСЯ ПОЛНАЯ ЛАЖА
Поэкспериментировал я с выгрузкой загрузкой товаров, по старому с поиском через код и по-новому через ЗначениеВСтрокуВнутр/ ЗначениеИзСтрокиВнутр – сумма остатков загруженных в базы разошлась на большую цифру – порядка 30 %
Начал рыть
Поскольку справочник номенклатуры был только первоначально скопирован на магазин, а потом новые элементы рождались параллельно в сводной базе и базе магазина, то их внутренне представление в этих разных БД различно (не у всех, но у части).
Ниже приведен пример одних и тех же товаров в разных базах, только первый товар совпадает по внутреннему представлению, остальные 2 – нет !!!
Сводная база
Товар = Абсент «Тунел Зеленый» 0,7*6 70% Испания
Товар.Код = «5065»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5061 «}»
Товар = Бренди «Кондор» ХО в п/к 40% 0,7*12 Франция
Товар.Код = «0»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5062 «}»
Товар = Абсент «Тунел Красный» 0,7*6 70% Испания
Товар.Код = «5066»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5063 «}»
База магазина
Товар = Абсент «Тунел Зеленый» 0,7*6 70% Испания
Товар.Код = «5065»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5061 «}»
Товар = Бренди «Кондор» ХО в п/к 40% 0,7*12 Франция
Товар.Код = «0»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5065 «}»
Товар = Абсент «Тунел Красный» 0,7*6 70% Испания
Товар.Код = «5066»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5060 «}»
Поэтому, как хотите, но поиск по коду товара, который всегда одинаков во всех базах – самое правильное решение. Во всяком случае у нас.
+53
Поправлюсь.
Для обрезания одной базы (выгрузка и загрузка в одной базе)- это подходит, но только из-за красоты кода — стоит ли переписывать?
А вот для выгрузок и обменов документами и справочниками между Сводной ба
(11) Проблема не «с аптеками», проблема с ДНК…
(55)
Надеюсь выскажу мнение большинства:
«Инфостарт не площадка для пикировок, а место для конструктивного диалога единомышленников» 🙂
(53) А какое отношение имеет код к внутреннему ID элемента справочника?
>>>>»Поэтому, как хотите, но поиск по коду товара, который всегда одинаков во всех базах – самое правильное решение.»
Бред сивой кобылы в лунную ночь…
Даже лень объяснять почему…
(57)(58)
Может мы о разном говорим?
Код — базовый реквизит элемента справочника.
Кроме того есть ещё внутренний ID элемента.
Они НЕ взаимосвязаны (у части товаров они совпадают(последняя цифра в ЗначениеВСтрокуВнутр), но потом разьезжаются).
Если говорить о том, что мы выгружаем документы, потом прибиваем их, в базе остаются только справочники, а потом мы загружаем документы обратно и нужно их заполнить по справочникам, то нам всё равно по чем искать по Коду элемента или по внутреннему ID, так как справочник как был до обрезания, так и остался после него.
НО, если у нас документы (Закуп, например), как и элементы справочника рождаются в Центральной базе, а потом мигрируют в БД удалённых магазинов,
то «Внутренний ID» использовать нельзя, я показал выше, что в разных базах «Внутренний ID» товаров различается (у меня на практике процентов 10-20 разьехалось).
А поскольку, при заведении элемента справочника в БД удалённого магазина, я принудительно устанавливаю ему КОД как в центре, то они у меня везде одинаковые — его и используем.
(58)
Отсылаю к моему посту (56)
(59) Ну привет.. если разные ID — это автоматом РАЗНЫЕ элементы.
Какая на синхронизация по коду может быть вообще ?
(59) > элементы справочника рождаются в Центральной базе, а потом мигрируют в БД удалённых магазинов,
то «Внутренний ID» использовать нельзя, я показал выше, что в разных базах «Внутренний ID» товаров различается (у меня на практике процентов 10-20 разьехалось).
ответ в (58)
С чем у тебя «Внутренний ID» товаров различается?
Ты не совсем понимаешь, как в базе хранятся элементы справочников.
«Нам всё равно по чему искать»
Ну что за бред..
Товаров с одинаковым кодом можно наплодить до едрени фени, а вот с одинаковыми ID — хрен.
И еще, у некоторых справочников, вообще нет ни кода ни наименования.
(1) > А вообще у нас ещё много разных интересных технологий 😉
А вот теперь не сомневаюсь :))
(62)
Правда, очень надеюсь, что понимаю 😉
А вообще, раньше даже и не заморачивался, описанная выше технология работает на обмен между центром и удалёнными торговыми точками более 13-ти лет.
Прикиньте и работает 😉
Не забывайте, всё пишем сами и под себя — с «нуля»
(63)
И справочники нужные у нас «с кодом» и крыжики уникальности кода стоят, там где надо, и коды мы сами рождаем в удалённых базах -в общем всё хорошо у нас и все счастливы.
Вернусь к (62)
Я привел пример:
Что один и тот же товар в сводной базе и базе удалённого магазина имеют раный внутренний ID
Сводная база
Товар = Абсент «Тунел Красный» 0,7*6 70% Испания
Товар.Код = «5066»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5063 «}»
База магазина
Товар = Абсент «Тунел Красный» 0,7*6 70% Испания
Товар.Код = «5066»
ЗначениеВСтрокуВнутр(Товар) = «{«B»,»0″,»0″,»14″,»0″,»0″,» 5060 «}»
То есть если я выгружу из сводной ID «{«B»,»0″,»0″,»14″,»0″,»0″,» 5063 «}»,
То в базе магазина он найдёт мне совершенно другой товар.
(65) Это — РАЗНЫЕ элементы с одним названием.. неужели не понятно?
(65) > То в базе магазина он найдёт мне совершенно другой товар.
И правильно сделает, т.к. это и будет совершенно другой товар.
> Правда, очень надеюсь, что понимаю 😉
Зря надеешься.
+ 66 Советую ознакомиться, на будующее
(66) Есть смутные сомнения, что у автора не УРБД, а самопальный обмен.
По молодости таким баловался, работало, но проклял все на свете.
А вообще, я это все затевал ТОЛЬКО для представления технологии использования BAT-файла.
Выгрузки / загрузки выложил по просьбе конкретных людей — они (эти обработки) ни на что не претендуют. Просто у нас вот так, и всё хорошо.
Если у вас тоже всё хорошо, но по-другому — замечательно…
(63)(64)
А вы правда верите, что я всю эту тему замутил, чтобы просто постебаться?
Реально, на всю работу потрачено много времени и экспериментов (не имею ввиду технологию выгрузки/загрузки их заготовки брал из того, что уже 100 лет используем, только доработал что нужно) — и работа завершена.
Результатом стало то, что в случае тормозов магазина из-за размера базы (а 500 это метров или 5 Гиг — без разницы).
Я звоню в магазин, управляющая входит в 1С, запускает обработочку, которая делает BAT-файл, выходит из 1С, запускает BAT-файл и идет курить.
10 — 20 минут и база обрезана до минимальных 100 Метров — можно работать.
Всё 🙂
(69) Нам этого не понять.. Люди понимашь, на собственной нетленке с !одним! регистром учет ведут 10 лет и режут базу при 500 метров..
А ты говоришь кода..кода..
🙂
(69)
Ага, самописное всё 🙂
Не, у нас нормально, всё катит.
(72) Так все-таки не УРБД?
Тогда вопросов больше не имею.
А у нас всё автоматизировано (ну почти всё)
На примере 1-го направления (деятельности).
Есть оптовая компания, которая работает с клиентами и тарит нашу розничную сеть на 95% номенклатуры — 1 база.
Розничная компания — 1 сводная + 135 (пока) удаленных магазинов (БД).
Примерный режим работы:
1.Офис-менеджеры приходят на работу, выбирают магазину к затариванию на завтра, хлоп кнопочку (анализируем остатки, оптимальный запас) – есть заявки.
2. Если нужно, офис-менеджеры их корректируют и хлоп кнопочку – заявки в БД оптовой компании выгрузились / загрузились в виде отгрузок (разбитые по тоннажу, складам, товарному составу)
3. Если нужно, офис-менеджеры их корректируют и хлоп кнопочку и эти отгрузки в виде закупа обратно в сводную базу розничной сети улетают, а заодно и корректировавшиеся (в оптовой базе) отгрузки предыдущих периодов (автоматом) прихватываются.
4. Офис-менеджеры хлоп кнопочку и этот «Закуп» и изменёнными закупами предыдущих периодов на магазины по инету уезжают. Каждый пакет на свой магазин.
5. Там управляющие их грузят.
Ну а справочники – вечером выгрузили – хлоп кнопочку – всё на магазины по инету уезжает.
И никакого УРБД-ного гемора…
Правда хочу вместо этих 4-к кнопок – 1 большую нарисовать, но руководство пока морально не готово :-)))))))))))))
P.S.
Перед новым годом около 100 магазинов были обрезаны в этом автоматическом режиме. Обрезали не только я программист, но и другие люди просто умеющие работать с компьютером (копировать например 😉 )
Грабли были, но единожды, из-за вирусов.
Вирус держал файл когда производилось первоначальное копирование базы и копирование слетело, прошла выгрузка, а потом по BAT-нику грохнуло все регистры и документы
Поскольку у меня таким образом не осталось копии ДО обрезания, пришлось тормозиться и вытаскивать ночную копию. Потом лечились от вирусов и всё по новой.
В дальнейшем стали перед обрезанием делать ещё одну предварительную копию, чтоб наличие вирусов вычислить…