forum.clarionlife.net

Добрый день. Не могу отконвертировать таблицы. При конвертации (tps) постоянно выдает два типа ошибок
- Error 40 Creates duplicated key
- Invalid record declarfation(possibly containingOVERed fields) this file cannot be browsed.
Что могло сбиться? Переустановка клаши ничего не дала.

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

softcreator писал(а):ничего не сбилось - первая ошибка очевидна, нужно избавляться от дубликатов в базе, вторая - следует из неполноценности функции конвертации средствами словаря (по сути предназначенных для случаев добавления полей в структуры - а не модификации имеющихся полей), нужно или генерировать программу конвертации средствами словаря или пользоваться шаблонами автоматической генерации кода коверторов.

Помогло следующее - раз 10 перезагрузился. Теперь конвертит без проблем. И вышеописанных ошибок не даёт.

Ну, ты даешь. Если у тебя есть реальная TPS-таблица с данными и ты решил поменять ее структуру, то тут прав Вадим: нужно сгенерировать модуль конвертации - это будет экзешник, который ты можешь разослать заказчикам -все это прекрасно работает.Но если тебе помогли перезагрузки компа , то я снимаю шляпу.

lsgsoftware писал(а):Ну, ты даешь. Если у тебя есть реальная TPS-таблица с данными и ты решил поменять ее структуру, то тут прав Вадим: нужно сгенерировать модуль конвертации - это будет экзешник, который ты можешь разослать заказчикам -все это прекрасно работает.Но если тебе помогли перезагрузки компа , то я снимаю шляпу.

Даже наврал немного - не перезагрузка компа как такового, а выход - вход в клашу. А где почитать поподробнее как генерируется модуль конвертации? А то достало постоянно перекачивать TPS - ки с удаленных филиалов, конвертить и рассылать обратно. Причем приходится останавливать ес-сно работу филиала.
Как я понимаю - это в File\Create conversion program ?

optron писал(а): Даже наврал немного - не перезагрузка компа как такового, а выход - вход в клашу. А где почитать поподробнее как генерируется модуль конвертации? А то достало постоянно перекачивать TPS - ки с удаленных филиалов, конвертить и рассылать обратно. Причем приходится останавливать ес-сно работу филиала.
Как я понимаю - это в File\Create conversion program ?

По мне так проще купить соответствующий продукт. Я давно уже пользуюсь "Data Conversion" (и не надо будет самому все время конвертировать таблицы). Один из разработчиков (или основной) Вадим Синявский. Правда, что-то на сайте http://www.nikasoft.co.uk - я не вижу этой разработки... Посему может ему лично отписать...

Вообще, это очень острый вопрос для профессиональных программистов(для тех, кто работает с заказчиками и получает за это деньги). Если проект живой и постоянно развивается, то изменение структуры таблиц вещь обычная и требует постоянного общения с заказчикоми. А вот как заставить заказчика переконвертировать базу без выезда к нему - это проблема.На мой взгляд, лучший вариант - это экзешник. Я уже давно не работаю с клашиными моделями данных
(ну моден SQL) и сижу на MYSQL, в котором есть прекрасная никсовская команда SOURCE. Подготовил текст изменений на SQL в виде текстового файла и скормил этой команде. Даже низкоквалифицированыый заказчик с этим вроде справляется.

Привет всем !

Тема действительно встречается в жизни на каждом шагу ...
Для TPS и Btrieve БД ее решил следующим образом:

- В словаре делается копия модифицируемого списка.
После этого в структуру исходной таблицы вносятся
необходимые изменения и ей присваивается новое имя файла.

- При запуске программы проверяется есть ли записи в файле,
если нет - запускается конвертер, который переписывает
записи из "старой" таблицы в таблицу с "новой" структурой.
При этом выполняются все необходимые действия (заполнение
новых полей на основании существующих, расчет и запись
итоговых значений, проверка правильности данных, фильтрация
и т.д., короче - все что нужно для конвертации).

- После этого записи из "старой" таблицы удаляются.
Операция конвертации снабжена индикатором и сообщением
типа "Пожалуйста подождите, идет обновление структуры данных ..."
файлы открываются в монопольном режиме,
есстесственно "переливание" записей выполняется под транзакцией.

- Вот и все. Пользователь загружает новую версию программы,
устанавливает ее, и при первом запуске, та сама вносит изменения
в структуру данных. И никаких проблем.
Такая технология работает еще с DOS Clarion 2.1. Рекомендую !

Вот чтобы избежать описанного кошмара, работающего с CPD2.1 и был написан много лет назад DC. В 99,9% случаев не требует ни единой строчки кода для настройки процесса (разумеется кроме всяких присвоений новых полей, фильтраций etc)

Ну как говорилось в великой книге: "Кому и кобыла - невеста ...".
Кошмара никакого нет, наоборот - мне, например, удобней работать
с открытым и полностью управляемым кодом, чем с чужим шаблоном.
С другой стороны - хорошо, что есть варианты и человек может
выбрать наиболее подходящий для него по его задаче и технике
работы с Clarion ...

Игорь Столяров писал(а):Ну как говорилось в великой книге: "Кому и кобыла - невеста ...".
Кошмара никакого нет, наоборот - мне, например, удобней работать
с открытым и полностью управляемым кодом, чем с чужим шаблоном.
С другой стороны - хорошо, что есть варианты и человек может
выбрать наиболее подходящий для него по его задаче и технике
работы с Clarion ...

В защиту DC: там нет никакого закрытого кода. Открытый шаблон. Все прозрачно и удобно.

С уважением Мартюшев Леонид

Игорь Столяров писал(а):Ну как говорилось в великой книге: "Кому и кобыла - невеста ...".
Кошмара никакого нет, наоборот - мне, например, удобней работать
с открытым и полностью управляемым кодом, чем с чужим шаблоном.
С другой стороны - хорошо, что есть варианты и человек может
выбрать наиболее подходящий для него по его задаче и технике
работы с Clarion ...

Вообще-то написание унивресального обработчика конвертации (чтобы потребовалось добавить только декларацию старой таблицы и 2-3 строки кода - с учетом нюансов даже только одного tps-формата) - задачка не очень простая... а если еще учесть все поддерживаемые форматы (и dat-ы обоих типов, dbf-ы, тот же сиквел мелкомягкий) - то весьма непростая... так что любителям она явно не под силу...

На мой взгляд, оптимальный вариант - это когда новая версия проги при запуске сама определяет,что структура таблицы изменилась и сама запукает конвертацию - я такие проги видел.Да и сделать это не так уж и сложно, но не универсально, а для каждого конкретного случая.Те же конвертационные экзешники можно запускать прямо из тела проги по определенному условию.Но проблемы остаются, если прога сетевая, а у заказчика нет квалифицированного админа(что в жизни сплошь и рядом).А вообще, это обсуждение желательно продолжить, т.к. проблема актуальная.

А вообще, это обсуждение желательно продолжить, т.к. проблема актуальная.

Блин, вот Вадим, он же softcreator выше - обращайся напрямую к нему с вопросом как получить DataConverter.
На этом актуальная проблема снимется.

Я свой голос отдаю за DataConverter как MUST HAVE и мега рулит.

зы
не знаю как насчет SQL

lsgsoftware писал(а):На мой взгляд, оптимальный вариант - это когда новая версия проги при запуске сама определяет,что структура таблицы изменилась и сама запукает конвертацию - я такие проги видел.Да и сделать это не так уж и сложно, но не универсально, а для каждого конкретного случая.

Дык уже сделано. Универсально. На все случаи жизни - конвертор (или встроенный или запускаемый - есть реализации как одна так и другая) сам детектирует факт появления ошибки 47 и запускает процесс конвертации. Причем для программера почти никогда ничего при изменении словаря делать не нужно - просто пересобрать приложение, содержащее конвертор.

lsgsoftware писал(а): Те же конвертационные экзешники можно запускать прямо из тела проги по определенному условию.Но проблемы остаются, если прога сетевая, а у заказчика нет квалифицированного админа(что в жизни сплошь и рядом).А вообще, это обсуждение желательно продолжить, т.к. проблема актуальная.

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

StillZero писал(а):

А вообще, это обсуждение желательно продолжить, т.к. проблема актуальная.

Блин, вот Вадим, он же softcreator выше - обращайся напрямую к нему с вопросом как получить DataConverter.
На этом актуальная проблема снимется.

Это понимают только те, кто попробовал 7 лет назад тестовую версию DC или купил

StillZero писал(а):

Я свой голос отдаю за DataConverter как MUST HAVE и мега рулит.

Собственно я тоже

StillZero писал(а):

зы
не знаю как насчет SQL

довольно хорошо в том, что касается mssql-драйвера и стандартного клашиного подхода к созданию сиквельных приложений. просто эта версия dc распространяется as is и претензии к работе под сиквелом не принимаются по причине кучи различных вариантов использования драйвера. а так - новые поля ловятся, изменения имеющихся тоже, модификации индексов также контролируются (хотя это довольно спорный момент - но я сделал так как было нам нужно), имеющиеся серверные триггеры при конвертации копируются в новые таблицы... что-то еще кажется было... при все при этом конвертация надежная и таблицы при обломах на разных этапах никогда не потеряются