Прога слетает на append и append from

Форум » Clipper » Прога слетает на append и append from » Ответить

Прога слетает на append и append from

Лукашевский: Clipper 5.2e + SixCdx2 + Blinker 7.0 + Protected mode При достаточно большом количестве добавляемых записей (в интервале 150 - 500, всегда по разному) прога слетает с сообщением типа: BLX286: 1313: General Protection Fault либо: DBSKIP(0) Внутренняя ошибка 1210 Отключаю от базы индексы - и всё прекрасно! Но в том-то всё и дело, что индекс нужен, чтобы не добавить то, что в базе уже есть (идёт проверка DBSEEK())... Кто-нибудь с таким фокусом сталкивался? Как бороться?

Ответов - 24, стр: 1 2 All

Dima: Покажи код

Dima: 5.4 What is "Internal Error 1210" and what can I do about it? (Reply supplied by Norman Mongeau.) Internal Error 1210 occurs when the database driver discovers an index file inconsistency with which it cannot cope. There are a few things you can check in your code to eliminate this error: Be sure that all indexes relating to a given .DBF file are open whenever key values are updated. (In other words, don't let your index files get out of synch with the data files.) Be sure that all your index key expressions resolve to the same length regardless of the key value. For example, you should avoid using TRIM() on the whole key expression because it would cause different records to have different key lengths. Avoid having many duplicate keys in the same index. One simple way to create unique keys throughout is to add something like (STR(RECNO()) to the key expression. Consider using a database driver other than DBFNTX. The conditions that cause IE 1210 do not occur in the other drivers. If you use DBCREATEINDEX() to create index files, make sure that the key expression character parameter is consistent with the key code block parameter. It's okay if these expressions are not exactly the same, but they must evaluate to the same result. http://www.davep.org/clipper/FAQ/clipper-5.html

Лукашевский: Кажись понял, в чём фишка, по крайней мере при append from: если в принимающей базе по какому-либо текстовому полю сделан индекс, и ширина этого (с таким же именем) поля в принимаемой базе больше чем в принимающей - вылетаем с сообщением "BLX286: 1313: exception error 0D: general protection fault: code = 0000h" или (ещё появился вариант! :) "DBSKIP(0) Внутренняя ошибка 1010". Попробуй сам. Причём это только с CDXами. В 5.01 с NTXами всё было путём.

Dima: Покажи ключ в INDEX , небось TRIM там ? :) если нет , должно помочь +str(recno(),12) или типа того. сам попадал на эти грабли.

Лукашевский: i_key = "PADR(ALLTRIM(knigy->avtor) + ALLTRIM(knigy->nazv), 50)" i_key = "knigy->avtor + knigy->nazv" i_key = "knigy->nazv + knigy->avtor" i_key = "PADR(UPPER(CHARONLY(cifrix, knigy->ISBN)), 14)" На базу навешено четыре индекса, TRIM ни в одном нету, в этом-то и странность возникновения ошибки. Буду теперь смотеть, на каком индексе прога грохается - на том, где "чистые" поля, или где PADR(). STR(RECNO) тоже попробую, спасибо. Но почему это вылезло только на CDXах, вот в чём ещё вопрос? Что-то в SIXCDX недоработано...

Dima: Ключи вроде верные ;) Под TRIM я имел в виду RTRIM , LTRIM , ALLTRIM Думаю Recno поможет. Лукашевский пишет: Что-то в SIXCDX недоработано... И не только в нем ;) SUV уже много раз говорил про это !

SergeJa: knigy->Лукашевский пишет: i_key = "PADR(UPPER(CHARONLY(cifrix, knigy->ISBN)), 14)" а указывать алиас в ключе - хорошо ли? первый раз встречаю такое.. Лукашевский пишет: Отключаю от базы индексы - и всё прекрасно уверен, что лучше отключить ... Лукашевский пишет: достаточно большом количестве добавляемых записей (в интервале 150 - 500 ... тем более при таком гиганском объёме данных Всем привет, кстати. 7-е ноя все празднуем, надеюсь?

ort: SergeJa пишет: 7-е ноя все празднуем, надеюсь? Сейчас нужны другие праздники. Если бы не 7 ноября - жили бы мы на уровне Швеции и Финляндии. Сказка!

SergeJa: В Швеции не было революций (а они на пустом месте не появляются). Войн (к революциям приводящим). Идиотов/гадов/предателей-правителей (у нас - с НиколаяII - такие). так что сравнение не катит. А праздновать 4-е ноября - нелепость. И оффтопик :)

Pasha: А как же, празднуем :) У нас 4 ноября нет, зато есть свой маразм

Dima: Лукашевский пишет: Буду теперь смотеть, на каком индексе прога грохается Скорее всего на том где он самый длинный.

Лукашевский: Dima пишет: Скорее всего на том где он самый длинный. В каком-то смысле именно так, но думаю, что длина индексного выражения не главное - самое смешное оказалось, что прога грохается на индексах, в ключах которых непреобразованные поля (т.е. "knigy->avtor + knigy->nazv" и "knigy->nazv + knigy->avtor")! Вот так фокус!

Лукашевский: SergeJa пишет: а указывать алиас в ключе - хорошо ли? первый раз встречаю такое.. Это-то как раз абсолютно нормально! В молодости я пытался делать индексы без алиасов в ключевом выражении, но столкнулся с тем, что если переходишь SELECTом к другой базе, в которой есть точно такие же по наименованию поля (как и в ключе прежней базы), индексы в прежней базе начинают изменяться в соответствии с содержимым полей текущей базы! :-( Странно даже, что ты с таким подходом до сих пор с этой проблемой не столкнулся!

Dima: Лукашевский пишет: индексы в прежней базе начинают изменяться в соответствии с содержимым полей текущей базы! :-( сумлеваюсь в этом.

Лукашевский: Dima пишет: Думаю Recno поможет. К сожалению, не помог... Не помог, как ни странно, и PADR() тоже... :( Буду дальше экспериментировать.

Dima: Commit делаешь ?

Лукашевский: Dima пишет: сумлеваюсь в этом. Можешь сумлеваться сколько угодно, а так действительно было и у меня с тех самых пор ни одного поля в ключевом выражении без алиаса нет... Было оно, правда, в 5.01 на NTXах - может, CDXы В ЭТОМ СМЫСЛЕ изменяются корректнее...

SergeJa: Лукашевский пишет: Странно даже, что ты с таким подходом до сих пор с этой проблемой не столкнулся! У меня нет таких проблем. И в молодости не было. Маленький пример (могу ошибаться с синтакисом, но принцип бед должен быть ясен) USE qqq.dbf SHARED ALIAS A1 INDEX ON A1->Fld TO qqq.NTX USE qqq.dbf SHARED ALIAS A2 SET INDEX TO qqq.NTX Понятно, или надо подробнее? Лукашевский пишет: грохается на индексах, в ключах которых непреобразованные поля И...? Вот так фокус! А нет никакого фокуса. Увы. Читайте книжки по программированию.

Dima: SergeJa пишет: грохается на индексах, в ключах которых непреобразованные поля И...? На самом деле такая проблема существует. У меня падало при добавлении в базу около 1000 записей или около того и тоже вот с такими длинными ключами. Str(recno()) не спасло. Уменьшил длину ключа и пока работает. Тож самое не падает под ADS , в SIX падает или может упасть.

Лукашевский: Dima пишет: Commit делаешь ? Это внутри append from? Нет, в принципе, наверное, можно засунуть его в условие FOR и делать Commit после принятия какого-то кол-ва записей, но фишка оказалась ещё и в том, что прога рушится после принятия 150-500 записей - это, оказалось, частный случай, а в общем случае не принимается НИ ОДНОЙ записи! Обрушение идёт сразу же! Как пример я взял совершенно пустую базу (но со всеми теми же индексами) и при попытке добавления к ней записей из другого файла по append from - сразу вылет с ошибкой BLX286: 1313: exception error 0D: General protection fault И весь фокус в том, что в принимаемом файле поле NAZV шириной 70, а в принимающей базе - 90! Когда делаю ширину одинаковой (70) - процесс проходит беспроблемно!

Лукашевский: SergeJa пишет: USE qqq.dbf SHARED ALIAS A1 INDEX ON A1->Fld TO qqq.NTX USE qqq.dbf SHARED ALIAS A2 SET INDEX TO qqq.NTX Понятно, или надо подробнее? Ничего не понятно... Одна и та же база, один и тот же индекс... Я говорил о ситуации, когда в двух разных базах (если непонятно - двух разных dbf-файлах) есть поле с одинаковым названием (например, поле NAZV в dbf-файле KNIGY.DBF и поле NAZV в dbf-файле SKLAD.DBF), если делать ключевые выражения без алиасов, то при работе и с одной и с другой базой индексы начинают рушиться. SergeJa пишет: цитата: грохается на индексах, в ключах которых непреобразованные поля И...? И ничего пока... Попробовал PADR(), как в первом и четвёртом индексах - не помогло! Может, действительно дело в длине индексной строки? Она получается 90 (NAZV) + 28 (AVTOR) = 118 символов... может, всё нормализуется именно тогда, когда я делаю ширину поля NAZV в базе 70 символов и длина строки получается 98 символов?

armik: Пользуй commit каждые n записей...

Лукашевский: Путём многочисленных экспериментов выяснил, что Dima был абсоблютно прав - всё дело в длине индексного выражения! Если длина индексного выражения больше 117, то прога рано или поздно грохается (причём скорее рано, чем поздно :-( В моем примере с длиной индексного выражения 118 по append from вообще ни одной записи принять не удаётся! armik пишет: Пользуй commit каждые n записей... Поэтому разговор об n записях теряет всяческий смысл...

Dima: Лукашевский пишет: Если длина индексного выражения больше 117 У меня падало и при длине 80....... Решить проблему смог только путем уменьшения длины ключа.

полная версия страницы