Форум » Clipper » Ошибка _DBFCDX/1020 для APPEND FROM » Ответить
Ошибка _DBFCDX/1020 для APPEND FROM
Andrey: /* Подскажите кто может. Как боротся с ошибкой: Error _DBFCDX/1020 Ошибка в типе данных Called from __DBTRANS(0) Called from __DBAPP(0) Called from MAIN(23) При копирование записей с одной базы в другую возникает эта ошибка. Я в структуру новой базы вставил с 58 поля 4 новых поля: NKODDOST;N;1;0 CKODDOST;C;25;0 SUMDVER;N;2;0 NKALITKA;N;1;0 И теперь при копирование записей возникает ошибка и на Clipper'e и на Harbour'e. Вообще-то это происходит всегда, когда добавляешь в DBFCDX-драйвер дополнительные поля в середине базы. Для решения этой проблемы приходиться запускать утилиту bdbfs.exe и ручками копировать с одной базы в другую. Достало это. Подскажите пожалуйста как решить эту проблему. Ниже привожу пример. */ FUNCTION MAIN() LOCAL aDbf #ifndef __HARBOUR__ #else REQUEST HB_CODEPAGE_RU866 hb_SetCodepage( "RU866" ) REQUEST HB_LANG_RU866 HB_LANGSELECT("RU866") #endif REQUEST DBFCDX RDDSETDEFAULT( "DBFCDX" ) USE ("dog_stru.dbf") ALIAS BASE_NEW EXCLUSIVE NEW aDbf := BASE_NEW->(DBSTRUCT()) CLOSE BASE_NEW DBCREATE("dog_new.dbf", aDbf) USE ("dog_new.dbf") ALIAS BASE_NEW NEW SELECT BASE_NEW SET DELETED OFF APPEND FROM ("dogovor.dbf") SELECT BASE_NEW ? LASTREC() wait RETURN NIL
Ответов - 31, стр:
1 2 All
Петр: Лукашевский пишет: И кстати, не будете ли Вы так любезны продемонстрировать Вашу функцию? Не буду В подобных случаях использую или команду APPEND FROM или соответствующую ей встроенную функцию. Еще раз внимательно рассмотрите код который Вы предлагаете использовать вместо APPEND FROM Function Append1From (from) local f_num, f_pos, f_get if PCOUNT() = 1 append blank endif for f_num=1 TO (from)->(FCOUNT()) f_pos = FIELDPOS( (from)->(FIELDNAME(f_num)) ) if f_pos > 0 f_get = (from)->(FIELDGET(f_num)) if VALTYPE(f_get) = TYPE(FIELDNAME(f_pos)) FIELDPUT(f_pos, f_get) endif endif next DBCOMMIT() return .T. Да она работает, да она проверяет тип поля, а дальше что. А если VALTYPE(f_get) <> TYPE(FIELDNAME(f_pos)) тогда FIELDGET(f_pos) что даст? Наверное не всегда то, что ожидалось. Вы ведь просто теряете данные! Не случайно в документации по APPEND FROM указывается, что КОПИРУЕМЫЕ ПОЛЯ ДОЛЖНЫ БЫТЬ ОДНОГО ТИПА, а то будет вам ошибка времени исполнения, а другими словами смотри, что делаешь, не будет Clipper за тебя думать! Хотите анализируйте структуру таблицы приемника и таблицы источника (с помощью DBStruct) до вызова APPEND FROM, хотите пишите обработчик ошибок, хотите пишите свою функцию и там ловите ошибки, хотите ничего не делайте, надейтесь что все будет нормально. Ну и сама реализация - код Димы пошустрее будет.
Andrey: Петр пишет: Ну и сама реализация - код Димы пошустрее будет. Петр ! Вы только отчасти правы. Здесь самое главное не быстродействие, а возможность сохранения записей из базы "приемника". И вы все расматриваете только одну ситуацию, а именно что база "приемник" целая, т.е. нет "битых" записей. Если они есть, то труба на всё. Т.е. нужно делать обработку и на прием "битых" записей. Я переодически с таким сталкиваюсь. И причину понять не могу.
Петр: Andrey пишет: Здесь самое главное не быстродействие, а возможность сохранения записей 1) Одно другому не помеха 2) речь именно о сохранении, а не о сознательной потере данных Andrey пишет: И вы все расматриваете только одну ситуацию Я рассматривал не ситуацию, а конкретный код и его возможное поведение Andrey пишет: а именно что база "приемник" целая, т.е. нет "битых" записей Здесь не совсем понял Вашу мысль, но если в базе (приемнике, источнике - неважно) действительно есть "битые" записи - "то труба на всё" Если серьезно, то ситуация не из приятных. Но, думаю, Вы что-то напутали с терминологией. Andrey пишет: Т.е. нужно делать обработку Согласен, и реализация такой обработки может происходить по разному. Разработчики APPEND FROM предложили свой вариант - не самый худший. Ни ГЛЮКОМ, ни ошибкой здесь и не пахнет, стандартное задокументированое поведение.
Andrey: Dima Дима, я тебе несколько файлов могу скинуть на мыло, там еще несколько моих функций сидят. Сюда кинуть не могу, слишком много.
Dima: Andrey пишет: Дима, я тебе несколько файлов могу скинуть на мыло cмотри личное сообщение (ЛС)
Andrey: Так, а как быть если записи базы откуда копируем "битые" ? Т.е. записей МЕМО поля нехватает, записи с мусором и т.д.
Dima: Andrey пишет: Т.е. записей МЕМО поля нехватает, записи с мусором и т.д. была та же проблема и не раз , клиенты меня просто задергали. в общем в Clipper я отказался от использования memo полей.
Andrey: Хорошо, с мемо-полями понятно, что информацию не востановить, а как быть при копировании записей, если Clipper или Harbour ругается на ошибку чтения и просто сваливается программа ? Как написать обрабоку такой ситуации.
Andrey: Дима, а где ты хранишь данные типа МЕМО-полей. Для них же по барабану кто "рушит", Клипер или Харбор. Да вообще-то рушит скорее всего система, откуда-же идет мусор ?
Dima: Andrey пишет: Дима, а где ты хранишь данные типа МЕМО-полей. В символьных полях длиной от 100 до 250 символов , больше не нужно было.
Петр: Andrey пишет: Хорошо, с мемо-полями понятно, что информацию не восстановить Попытаться можно. Например с помощью программы ASC (Advantage and SIx Commander) (автор Юрий Сухарев: suv - частый гость этого форума). Файл ->Доктор - совмещает проверку заголовка, memo, а также содержимого НЕ-memo полей (например, для поиска переполнения *** в числовых полях) (это из описания). Или вручную. Да вообще-то рушит скорее всего система, откуда-же идет мусор ? Этот вопрос в сети обсуждался довольно часто. Ищите. Устранить причину разрушения memo надо в первую очередь. Лично я храню MEMO или в dbt (проще структура, легче восстанавливать, размер при современных объемах ЖД значения не имеет), или в базе символьное поле - путь + имя файла (или просто имя файла), MEMO соответственно в указанном файле ( txt, rtf, doc, xls, jpg - в общем, что нужно). При втором подходе есть свои плюсы и минусы. Но все можно решить.
полная версия страницы