<?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='\
После повторных тестов пришел к выводу:
Доп.Индексы — да ускоряют получение данных,
но эффект явно виден при закэшированной(в ОЗУ SQL-сервера) базе данных!
******************************************************
******* Принудительное КЭШИРОВАНИЕ на SQL СЕРВЕРЕ******
(эффективно если на SQL сервере ОЗУ больше чем размер Базы)
методики см. в описании ниже по тексту))
Идея взята путем переработки информации из следующих источников:
*********************
Автор плагина для обмана 1с 7.7 насчет доп.Индексов
***********************
Запрос №1 (что то похожее порой шлет сама 1С)
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID
Время выполнения: 10203 мс
——————————————————————————
Запрос №2 — видоизмененный запрос 1 без указания индекса
Select top 50 * from SC46 order by SP4135, ROW_ID
Время выполнения: 4105 мс
————————————————————————————-
Запрос №3 — Добавим Все Поля входящие в Индекс
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, Descr, ROW_ID
Время выполнения:156 мс
********************
А чтобы ОдынЦэ не убивало ЛЕВЫЕ)) индексы берем разработку -скрипт-плагин для OpenConf -файл приложен + Обработка загрузки БД в память SQL))
…..BINconfigscriptsExtDD.vbs
и
….Каталог_Инф_Базы1cv7.ddx (Эти индексы в БД SQL создаст Конфигуратор при РЕСТРУКТОРИЗАЦИИ БД)
пример куска содержания моего DDX
X=RA405 %#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
X=RA405 %I=MY_IDDOC | |0 |IDDOC |0
Перейти к публикации
Вот низачто не поверю что в типовой 1С изменений индекса ускорит запись документа в 10 раз и после этого он станет писаться в 5 раз быстрее чем дбф (чтения у скуля и так быстрее, чем у дбф, а вот запись всегда хромала)
(0)
Сделайте замеры во всех режимах с перезагрузкой системы.
Т.е. исключите влияние системного и СУБД-шного кэширования.
(2) Проведение документа вряд ли сильно ускорит. Например, регистр остатков в ТиС. Измерения Фирма/Склад/Номенклатура. По ним троим есть комплексный индекс. Все трое известны при проведении документа. Индекс достаточно оптимален. Вот для отчетов добавление своих индексов может кардинально ускорить быстродействие.
(0)
А разве простые индексы по одному полю не добавляются установкой галочек «Отбор движений» и «Отбор итогов» ?
(4) )) Конфигуратор 1с 7.7 фигачит Составные Индексы и другого не дано, а с Регистрами вообще все плохо((,
моя статья приводит только пример — Тест Технологии)), я согласен что простые индексы — не всегда оптимальны. Просто тестировал данную технологию.
А вот как раз по примеру из начала статьи.
Запрос №1
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID
Можно для Этого случая составить Индекс из Двух полей SP4135, ROW_ID пусть Будет «SP4135_ROW_ID» , ТОГДА SQL при составлении плана запроса
сделает примерно так Select top 50 * from SC46(NOLOCK INDEX=SP4135_ROW_ID) order by SP4135, ROW_ID,
тогда выйдем примерно на те же «Время выполнения:156 мс » и возможно даже быстрей ибо всего Два поля в индексе а не три)) размер то меньше однако!
(1) запись при добавлении доп.Индексов — согласен замедлится, это логично писать надо будет и в таблицу и + в доп индексы.
Но вся проблема в том что НАПРИМЕР «расчет итогов регистров» при проведении не на ТА занимает от 60 до 85 % времени проведения.
Проведение документа вряд ли сильно ускорит. Например, регистр остатков в ТиС. Измерения Фирма/Склад/Номенклатура. По ним троим есть комплексный индекс. Все трое известны при проведении документа. Индекс достаточно оптимален. Вот для отчетов добавление своих индексов может кардинально ускорить быстродействие.
а Связь Регистра с Таблицей ЖурналаДокументов и Справочников — вы уверены что все индексы будут использоваться ОПТИМАЛЬНО? ))
(1) про запись я и не писал)) я написал что общее время ПРОВЕДЕНИЯ ускорилось в 10 раз по сравнению с БД на SQl(стандарт) и в 5 раз быстрей DBF БД(стандарт)
так ведь это боян тыщелетней давности, еще кажется на итлэнде проскакивал этот ddx
(9) да плагин оттуда. Плагин нужен только для обмана 1С что у нее все в порядке с индексами и левых типо нету))
(2) Уважаемый Владимир — ваши разработки насчет СУБД для DBF(ну или почти DBF), я пробовал/тестировал, но таки там без изменения КОДА 1С ускорения не достигнуть))
Тесты более подробные — наверное закину после выходных, как буду на работе.
(11)
Я не вижу связи между Вашей публикацией и моими разработками.
А посмотреть результаты (замеры) тестов будет интересно.
Думаю, имеет смысл их обнародовать в «моих» темах форума.
Но, только с учетом моего замечания из #2 сообщения данной темы.
А вообще…
Народ прошу помощи как АВТОМАТИЗИРОВАТЬ создание Оптимальных Индексов, догадываюсь что сбором ТРАСС в SQL Server Profiler и потом прогонять в Database Engine Tuning Advisor, т.е. на выходе получить готовый скрипт с созданием индексов!
MS SQL 2008
(12) Связь одна есть)) УСКОРИТЬ работу 1с 7.7
притом изменяя как можно меньше кода))
(14)
«УСКОРИТЬ работу 1с 7.7″(с)
Интересная разработка:
(6) А что тогда понимается в статье под «время проведения 1 документа»? Разве сюда не включается запись? Или это чисто теоритическое время получения итогов в вакууме?
(8) «общее время ПРОВЕДЕНИЯ» — что сюда включается? Разве это не получение итогов + расчет/контроль + запись (!)?
(16)(17) уважаемый Alav прочитайте пожалуйста сообщение (6), время записи у меня в SQL базе НИЧТОЖНО малО ! ))
(18) Еще раз читаю статью
3.1)SQL БД- стандартная Среднее время проведения 1 документа(19 строк) 30 сек
3.2)DBF БД- стандартная Среднее время проведения 1 документа(19 строк) 15 сек
3.3)SQL БД + добавление простых Индексов по КАЖДОМУ полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ…) — Среднее время проведения 1 документа(19 строк) 3 сек
С учетом (6) правильно ли я понял, что у вас в дбф расчет занимает 14,5 сек и сама запись 0,5 сек?
Правильно ли я понимаю что в SQL у вас расчет занимал 29 сек, а запись 1 сек
Т.е. у вас скуль получал итоги в 2 раза медленее чем дбф??? Простите вы скуль на первом пне с 64 метрами поставили?
Ведь как вы сказали добавления индексов не ускоряет запись (что логично), т.е. в можно предположить, что в п. 3.3 в 3 сек грубо говоря расчет — 2 сек + 1 сек запись
Я пока что всё верно рассуждаю?
(19)Alav,
Т.е. у вас скуль получал итоги в 2 раза медленее чем дбф??? Простите вы скуль на первом пне с 64 метрами поставили?
1) SQL стоит на серверной платформе 4-ех ядерный Проц., RAID 10, 40 Гб ОЗУ.
2) Оболочки 1с 7.7 запускаем тоже на серверной платформе на Терминальном сервере 4-ех ядерный проц, RAID 10, 10 ГБ ОЗУ.
С учетом (6) правильно ли я понял, что у вас в дбф расчет занимает 14,5 сек и сама запись 0,5 сек?
не совсем верно, Расчет регистров занимает от 60-85%, но есть же еще партионные алгоритмы и т.д.
А насчет использования DBF без СУБД хочу закончить наш спор, моему подразделению(Производство -одно из …в крупной торговой фирме)) ) не подойдет:
1)Объемы БД не те (SQL бд уже 25 ГБ) (притом восстановление последовательности доков в отдельной БД — потом Синхронизируем УРБД)
2)Объемы документооборота все время растут
3)работа в программе КРУГЛОСУТОЧНАЯ — следовательно никакие многочасовые ПЕРЕ-ИНДЕКСАЦИИ неприемлемы.
4)Урезки/Порезки тоже не пойдут.. отчетность будет проблемна… налоговая… собственник фирмы и т.д.
Не хочу никого обидеть, но 1c 7.7 +DBF без СУБД — ИМХО для «ларьков»! ))
(20) Я все еще пытаюсь понять откуда 3 сек. Но пока что не могу понять
было 30 сек * 85% = 25 сек расчет регистров
Значит на оставшиеся проверки и записи остается 5 сек
Индексы не дадут ускорения оставшейся части (проверки и записи). Значит после «правильных» индексов время проведения должно быть
новое время расчета + более 5 сек = время как минимум больше 5 сек. А по вашим расходам — 3 сек. Я вот понять не могу где и у кого ошибки расчета?
P.S. На разных база что ли тестировали, или откуда данные про проведения в дбф, если у вас база большая?
(21)
Индексы не дадут ускорения оставшейся части (проверки
утверждение НЕВЕРНО! Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников — также ускорит работу(поиск и получение данных) с ОБЪЕКТАМИ 1С в самих программных модулях языка 1С.
P.S. На разных база что ли тестировали, или откуда данные про проведения в дбф, если у вас база большая?
Да есть другая БД DBF, база отличается от SQL, но только объемом данных — а не Конфигурацией.
т.е. в DBF даже меньше данных значительно!
(22) В чем неверно?
(23)
(22) В чем неверно?
Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников — также ускорит работу с ОБЪЕКТАМИ 1С в самих программных модулях языка 1С.
я кажется понял почему помогло даже тупое) добавление Простых Индексов по каждому полю больших таблиц!!
Все равно не согласен с методикой сравнения. Сравнивать, теплое с мягким, и на основании этого делать вывод, что красное лучше зеленого.
Alav,
Каждому свое))
Но название статьи «Ускорение 1С 7.7 SQL в 10 раз и более — Созданием Нестандартных ИНДЕКСОВ»,
а не сравнение DBF с SQL
3.2)DBF БД- стандартная
Среднее время проведения 1 документа(19 строк) 15 сек — приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!
Это полный ПЭ..
Что такое ДБФ без СУЮД ? Это как ?
Если что, база 18 гигов в ДБФ, среднее время проведения 1 документа <1 секунда на ТА и чуть больше в заднем числе.
+28 ну и построение нестандартного индекса ну никак не приводит к ускорению ЗАПИСИ..
Получение останков с использованием своего индекса, да, ускорит, а вот запись — нет.
(29)Ёпрст,
про запись я и не говорил)) это Alav, уперся))
(28) DBF с СУБД , это разработки типо
«УСКОРИТЬ работу 1с 7.7″(с) Интересная разработка:
или на СУБД Advantage, CodeBase 6.5 от hogik,
(30) у меня обычная дбф база.
Попробуй «обгони» на скуле..
🙂
Комплексная, 2 плана счетов, добавлены ресурсы для упр учета во все регистры.
База крутится 24 часа в сутки, рег. работы в воскресенье.
Перепровод — сутки — 1 год.
Что я делаю не так ?
(31) единственный минус — реиндекс, на новом сервере, 15-20 минут, на старом 30-40.
+32 юзверей, 60-70.
Ёпрст, хорош флудить)), статья про 1с 7.7 SQL, а не сравнение с DBF
вот это по делу)))
Получение останков с использованием своего индекса, да, ускорит, а вот запись — нет.
Я не уперся, я просто хочу посмотреть на тот скуль, который при прочих равных условиях рвет дбф в 5 раз по скорости записи (проведение реализации)
(35)Alav,
у тебя есть SQL сервак?
загони туда свою базу…. желательно очень большого объема.
а на самых больших табличках навешай индексов по каждому полю, а еще на _1SJOURN — это в обяз))
****************************************************
например моя Тестовая SQL БД(рабочая еще больше)
ТАБЛИЦА /Колич записей.
_1SACCSEL /29 792 921 -Отбор Счетов
……….
…….
_1SSBSEL /10 332 026
_1SENTRY /8 812 137
RA328 /5 623 467 — регистр
RA4674 /5 563 064 — регистр
RA405 /5 506 885 — регистр
………………..
……………….
PS: т.е. в таблицах МИЛЛИОНЫ и ДЕСЯТКИ миллионов записей!
SQL скрипт получение количества записей
select o.name, i.rowcnt from sysobjects o
inner join sysindexes i on i.id = o.id where o.type = ‘u’ and indid = 1
Чем больше база тем быстрее проводиться? Я же непротив что при определенных условиях правильно настроенный скуль (в том числе и индексы) будет быстрее чем типовой.
Я просто хочу понять, как у тебя без прямой записи в скуль время проведения в 5 раз меньше, чем в дбф
Если бы ты написал, что время проведения в дбф — 1,5 сек. А в скуль, при правильных индексах — 3 сек, я бы и слово не сказал бы. В это я охотно поверю. Но 15 сек VS 3 сек на скуле средствами 1С — для меня выглядит, мягко говоря, невероятно
Ладно проехали. Ждем нормальное тестирование на сопоставимых данных
Ладно проехали. Ждем нормальное тестирование на сопоставимых данных
(0)
… … (sanfoto)
При создании индекса просматриваются все записи таблицы.
И «умные» СУБД оставляют данные в оперативной памяти.
А «глупые» СУБД — не оставляют, но это за них делает операционная система.
После этого система по чтению работает быстрее, чем до создания индекса.
Но после перезагрузки сервера (железа) скорость чтения возвращается к первоначальному состоянию. А запись начинает работать, естественно, медленнее из-за лишних индексов.
Присоединяюсь к сообщению #41:
«Ждем нормальное тестирование на сопоставимых данных»(с)
(39) конфа не типовая у меня.
Нормальное(т.е. перезагрузка и т.п.) тестирование на рабочих серверах никто не даст мне сделать.
Буду раскачивать виртуальную тачку… как раскидаюсь с делами на работе))
(42) да похоже дело было в случае SQL в КЭШИРОВАНИИ
первоначальный замер проводился после Группового проведения документов…нужно было для сбора трасс в ПРОФАЙЛЕРЕ
сегодня перезагружали сервера
сделал новый замер время проведения в SQL БД(тестовой) 27 секунд..
скорей всего тему закрою((
hogik,
Alav,
Ёпрст,
vcv,
спасибо за участие в обсуждении… ибо в споре рождается истина))
(44)
«время проведения в SQL БД(тестовой) 27 секунд»(с)
И это очень медленно для документа в 19 строк на таком железе.
Есть над чем работать…
(45) на движке v7dbnet
тот же док 19 строк
1)время проведения без установки ТА на документ 5 сек
2)с установкой ТА на док 0,5 сек
(46)
Я не призываю использовать альтернативные «движки» в части повышения скорости.
Думаю, прежде всего надо пересматривать концепцию самой 1С.
Т.к., по моему опыту, без такого пересмотра — смена «движка» не очень помогает.
Признаюсь, я уже «не понимаю» таких слов как: «без установки ТА/с установкой ТА».
У нас нет никаких ТА уже больше десяти лет… 😉
Процедура ПриОткрытии()
ЗагрузитьВнешнююКомпоненту(«rainbow.dll»);
КонецПроцедуры
Процедура Сформировать()
ЗапросРадуги=СоздатьОбъект(«ODBCQuery»);
СЗ=СоздатьОбъект(«СписокЗначений»);
ТекстЗапроса=»Select RTRIM(CONVERT(char(30),TABLE_NAME)) from INFORMATION_SCHEMA.TABLES
|WHERE TABLE_TYPE=’BASE TABLE’ AND TABLE_NAME<>’dtproperties'»;
Если ЗапросРадуги.Prepare(ТекстЗапроса,0,0)=1 Тогда
Если ЗапросРадуги.Open()=1 Тогда
ЗапросРадуги.GotoNext();
Пока ЗапросРадуги.IsOK()=1 Цикл
СЗ.ДобавитьЗначение(ЗапросРадуги.GetString(0));
ЗапросРадуги.GotoNext();
КонецЦикла;
ЗапросРадуги.Close();
Иначе
Предупреждение(«Ошибка открытия запроса!»,10);
Возврат;
КонецЕсли;
ЗапросРадуги.Reset();
Иначе
Предупреждение(«Ошибка выполнения запроса!»,10);
Возврат;
КонецЕсли;
Для к=1 по СЗ.РазмерСписка() Цикл
Если ЗапросРадуги.Prepare(«SELECT COUNT(*) FROM «+СЗ.ПолучитьЗначение(к),0,0)=1 Тогда
Если ЗапросРадуги.Open()=1 Тогда
ЗапросРадуги.Close();
КонецЕсли;
ЗапросРадуги.Reset();
КонецЕсли;
КонецЦикла;
ЗапросРадуги=»»;
Предупреждение(«Память для базы данных выделена!»,10);
Сообщить(«Память для базы данных выделена!»);
КонецПроцедуры
//________________________________________________________
(48) загружает БД в Память SQL сервера))
эффект КЭШИРОВАНИЯ достигнут!!!!! ))
(49)
Да. Есть такой способ.
Это работает во всех задачах ввода/вывода.
Сделайте, пару раз, копию файла на локальном диске.
Копирование второй раз будет в 10 раз быстрее… 😉
Вроде, я об этом и написал в сообщениях #2 и #42 данной темы.
И ЧТО мы обсуждаем? 🙁 🙁 🙁 …
странно, почему никто не минуснул за:
— перепост;
— абсурдные выводы;
И ЧТО мы обсуждаем? 🙁 🙁 🙁 …
да уже наверное нечего обсуждать)) тема была создана для выяснения так сказать ИСТИНЫ))
а еще думаю кому то поможет.
— абсурдные выводы;
выводы … хм, по 1с 7.7 +SQL
1)правильные доп.индексы — да ускоряют получение данных.
+
2)принудительное Кэширование данных в SQL — да ускоряет(завтра буду автоматизировать сей процесс 😀 ).
*********** работает есно эффективно если у SQL сервера МНОГО оперативной памяти…. больше БАЗЫ ДАННЫХ хотябы на 2 ГБ.
—сделав пункты 1) и 2) я опять вышел на те же 3 сек. проведения дока(19 строк) )))
—если исключить пункт 1) и выполнить только п. 2), то
а) до кэширования -проведение 30 сек.
б) после кэширования около 9 сек.
спасибо, кэп. Ну тогда плюс поставлю 🙂
Если вот уж совсем быть флудером, то мне вообще непонятно желание сделать индексы по ВСЕМ полям таблиц… чем-то мне это напоминает поиск наиболее вкусного яблока путем перенадкусывания всех яблок 🙂
(48) Сделал себе кэширование по Вашему посту, но прироста не получил. Тестировал на Групповой обработке(проводил 77 документов, которые медленнее всего). Результат:
— до Документ.ЗаказНаряд.Модуль Документа 1456 ПроведениеПоРегистрам(); 77 705.314887 99.02
— после Документ.ЗаказНаряд.Модуль Документа 1456 ПроведениеПоРегистрам(); 77 725.706179 99.15.
Т.е. ускорения не произошло. Объем базы 10,6Гб, ОЗУ 16Гб, MS Sql Server 2000 SP4, Windows Server 2003.
Мне не понятно, процедура «Сформировать()» должна запускаться каждым пользователем или достаточно чтобы только первым? Может я что-то не правильно делаю?
(55) Да не нужно делать никакого кеширования вообще.
не получите от этого никакого выигрыша.минимум не станет хуже.
sql сервер гораздо лучше знает
что ему надо а что не надо кешировать.
простой пример предположим у Вас есть очень большой документ Счет ( по размеру sql таблицы)
и Вам надо провести 10 000 расходных накладных. Загнав все счета в кеш Вы съедите
у sql сервера память(буферную) ( со временем конечно все сбалансируется но на время балансировки
памяти будет меньше у sql сервера да и на то чтобы снова все сбалансировать (выпихивать счета)
тоже понадобиться ресурсы sql)
Подскажите, как создать файл .ddx? Ато везде написано, как его использовать, а как создавать — нигде не нашел….
(0) Оформи статью пожалуйста. За такое оформление минус, без относительно содержания.
(57) al_zzz,
файл .ddx — формат с примером внутри файлов на скачивание.
(58) awk,
Оформить немного в лом)).
Тема лично для меня уже неактуальна.ИМХО полностью перешел на платформу 8.2.
Но если подскажите что не нравится — поправлю.
Выложи пожалуйста свой ddx для комплексной базы. а то чет туплю с его написанием
можно прямо тут текстом
написал ddx как в примере ток с регистрами из комплексной — при загрузке выдает ошибку в строке
строки из dds
#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
I=FASTACT | |0 |DATE_TIME_IDDOC,SP4062,SP408,SP418 |0
вот на вторую строку ругается 🙁 Что не так? Подскажите!
Так методом тыка…
заменил в ddx
FASTACT на MY_IDDOC
DATE_TIME_IDDOC на IDDOC
чет это ни где не было описано, и в скачанных файлах примерчик ddx неправильный
(63) MICK77,
это из-за различия названия полей в SQL БД — скорей всего..
В моей базе в dbo._1SJOURN у меня есть таблица DATE_TIME_IDDOC
После создания доп. индексов для документа, столкнулся с ошибкой при записи документа в таблицу — Violation of PRIMARY KEY constraint ‘PK_DH…’. Cannot insert duplicate key in object ‘dbo.DH…’
Оказалось, что ошибка возникает, если доп. индекс расположен в файле DDS до основных индексов и, соответственно, создается до того, как создан основной индекс. Если расположить в файле DDS доп. индексы после основных, то все работает.
Поэтому пришлось немного переделать скрипт, чтобы строки с доп. индексами добавлялись после основных, если они есть.