forum.clarionlife.net

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

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

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

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

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

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

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

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

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

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

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

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

Привет Всем!
Я, в 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-я строка шаблона, содержит: Вопрос - как обойти данную ситуацию, что поменять в синтаксисе? и как обойти ошибку 8 о недостаточности ресурсов?

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

Спасибо

Надо искать в шаблоне, где декларируется и используется символ %Parameters. Выглядит так, как будто в языке темплейтов после с6 был добавлен встроенный символ с таким же названием (что-то подобное было на память). В этом случае достаточно было бы его переименовать.

finsoftrz писал(а): 22 Февраль 2026, 16:51 Надо искать в шаблоне, где декларируется и используется символ %Parameters. Выглядит так, как будто в языке темплейтов после с6 был добавлен встроенный символ с таким же названием (что-то подобное было на память). В этом случае достаточно было бы его переименовать.

Вячеслав, Спасибо!
Переименовал %Parameters в %dcParameters, и ошибка ушла ! Возможно, в более новых версиях (после 6.3), испльзование Parameters стало "зарезервированным" средой.

Приветствую всех!
Ну что я могу сказать о своем шаблоне - не менялся он уже почти 10 лет (последний раз в 2017-м), но текущая версия 1.93 гарантированно совместима с C10 и C11 (практически уверен, что с C12 - просто не использую эту версию по ряду причин).
Не поленился и полез в закрома, взял тестовый набор приложений для создания мульти-dll примера, подключил DC - все собралось и конвертнулось без вопросов и проблем (Converter Mode = Internal - разумеется). Так что все перечисляемые в топике проблемы были решены в годах, эдак, 2010-2014...
Приобрести можно через IngaSoft - https://www.ingasoftplus.com/ProductDet ... ductID=259.
С вопросами, связанными с текущей версией (но никак ни с древностью образца 2005 года!), лучше обращаться лично на мыло softcreator68@gmail.com, сюда я захожу крайне редко, вплоть до того, что потерял старый логин

VadimS писал(а): 03 Март 2026, 10:00 сюда я захожу крайне редко, вплоть до того, что потерял старый логин

Вижу только Vorchun на мыло vadim#softcreator.com но там тоже всего два сообщения.
Более старого не помню.

Admin писал(а): 03 Март 2026, 13:34 Вижу только Vorchun на мыло vadim#softcreator.com но там тоже всего два сообщения.
Более старого не помню.

Возможно использование мыла softcreator@inbox.ru. Убей не вспомню какой был логин раньше - но писал сюда явно больше двух раз