Data Conversion - multy DLL

gopstop2007

kreator писал(а): 18 Февраль 2026, 22:33 Ругается на conv_data.clw. Что в этом файле и что в самом шаблоне? Кстати, что этот шаблон конвертирует?

Следит за изменениями структуры файла данных и если есть изменения конвертирует данные.

kreator

gopstop2007 писал(а): 20 Февраль 2026, 13:16 Следит за изменениями структуры файла данных и если есть изменения конвертирует данные.

Уже объяснили, спасибо. Что в шаблоне?

kreator

finsoftrz писал(а): 19 Февраль 2026, 20:21 У меня таких ситуаций за 20+ лет не возникало, все полностью автоматически. Возможность выстраивать ручной код есть, но эта опция не используется.

Понятно. У Вас всё просто и под контролем. Но универсальный шаблон так делать нельзя. К примеру, если надо добавить поле/столбец и дать ему какое-то значение? Ещё интересней, если значение надо дать в зависимости от значений других полей записи.
По поводу истории вообще промолчу. Мне это непонятно. Одна итерация (вместо всех сделанных) сразу ведёт к потере данных. Простые операции (типа добавление "нулевого" поля) не в счёт.

finsoftrz

Конвертор решает задачу актуализации структуры базы данных. Установить значение полей можно вставкой ручного кода. Этот код привязывается к номеру версии таблицы. Как я написал, на практике это не прижилось. Возможно, зависит от того, как проектируется база данных. У меня она максимально плоская.
Наверно, я не так понял, что такое итерация. Как уже написал, конвертор это одна процедура с множеством рутинок, вызываемых последовательно. Каждая из рутинок предназначена для конвертации версии одной таблицы в последующую версию. В разделе data мы имеем декларации всех версий всех таблиц, у которых имя и префикс дополняются номером версии. Каждой рутинке соответствует 2 структуры из деклараций, исходная и целевая. Вначале пытаемся открыть исходную таблицу, если открылась без ошибок, значит ее надо конвертировать в целевую таблицу. Если ошибка, то эта рутинка относится к предыдущей версии. Таким образом, конвертор пытается последовательно открывать таблицы в базе данных с самой первой декларации в истории. Как только срабатывает открытие без ошибки, мы нашли текущую версию на стороне клиента и дальше уже начинается последовательная конвертация на последующие версии. Иными словами, если в истории было два изменения структуры таблицы относительно структуры у клиента, то будут последовательно выполнены две рутинки, соответственно, две операции по конвертации.

finsoftrz

Еще такой момент. Изредка бывает потребность что-то изменить именно в значениях полей в базе данных. У меня это отделено от актуализации структуры и называется "патч" базы данных.
Когда-то в конце 90-х пришлось поработать в филиале одного московского банка, который внедрял импортную банковскую систему, работающую на субд Oracle. Москвичи часто присылали скрипты на sql c инструкцией по их запуску и что должно выдаваться после выполнения. Они называли эти скрипты "патчами". Название вполне выразительное, позже я его позаимствовал. Разница была в том, что у них патчи могли включать и изменение структуры базы данных. С плоскими таблицами оказалось эффективно разделить это на две независимые части - чистая актуализация структуры базы данных, которая полностью автоматическая, и патчи, которые отвечают за изменение каких-то данных в базе. Патчи случаются крайне редко, а актуализация структуры базы данных это регулярно используемый инструмент.

kreator

Да, понятно про итерации. Не уверен, что реакция на ошибку при открытии надёжный вариант. Ну да ладно. И ещё. Мой опыт показывает, что "патчи" (в вашей интерпретации) очень востребованы.

finsoftrz

Москвичи нам часто патчи слали. У меня они редкие гости. Как уже написал, зависит от подхода к архитектуре базы данных и используемой системы хранения (sql или isam). Я предпочитаю максимально плоские таблицы, не храню в них без надобности значения, которые можно получить программно. То есть, база данных и бизнес логика разделены. Это намного проще сделать какую-то функцию бизнес-логики в dll и обновить простым копированием всем клиентам, чем хранить это в базе данных и патчить каждый раз у всех клиентов.

kreator

Вас же не парит быстродействие. А когда есть SQL, трудно понять как себя поведёт планировщик запросов. Часто приходится и индексы менять, и поля перестраивать. И никто не великий. Если в фильтр (в конструкции "where") поставить какое-нибудь выражение или функцию, то сервак будет справляться с парой сотен записей (при этом планировщик будет перебирать все записи). Условно, на миллионе записей будут уже явные тормоза. Пользователь начинает писать претензии. Надо уже что-то делать.

finsoftrz

Вопросы быстродействия у всех есть, только они решаются разными способами. У нас действительно нет планировщика запросов, изначально точно прописано, как получить нужные данные оптимальным способом. И да, у пользователей задача молотить миллион записей возникает не так часто.
Бывает, конечно, иногда, что приходится добавлять индекс для обеспечения нужной производительности. Последний раз тако было, наверно, лет 5 назад, когда потребовалось получать последнюю цену закупки по товару в конкретном магазине на заданный момент времени. Причем получать надо очень быстро, потому, что функция вызывалась многократно внутри другой довольно сложной бизнес логики. Потребность возникла по ходу дела, в связи с изменением методики подсчета себестоимости на накопившемся размере базы данных.

SergioRaguzini

Привет Всем!
Я, в 2003 году, приобретал Data Conversion Template, и потом пару раз обновлял версии данного шаблона. На мой взгляд очень удобно - все изменения структур автоматом отслеживаются, пользуюсь до сих пор.
Но вот с чем столкнулся и в чем прошу помощи - при использовании данного шаблона в среде C6.3 все работает нормально, а вот если делать сборку приложения в С11 и с активацией версии С6.3

то все приоложения от C6.3 с "классическими" шаблонами (Legacy или ABC) компилируются нормально и без ошибок, а вот собственно app предназначенного для конвертации таблиц и выделенного в отдельный exe-шник (использует как раз DC.tpl) дает, при сборке, ошибку

TPL: (DC.tpl) Error: %Parameters is read only

Эта, 600-я строка шаблона, содержит:

Код: Выделить всё

#SET(%Parameters,'(LONG PAR:Version)')

Вопрос - как обойти данную ситуацию, что поменять в синтаксисе? и как обойти ошибку 8 о недостаточности ресурсов?

Error(8): cifm$lnew Недостаточно ресурсов памяти для обработки этой команды. -

: DC_Question3.png (4.6 КБ) 29 просмотров

Спасибо