Отправлено: 05.11.06 03:07. Заголовок: Прога слетает на append и append from

Clipper 5.2e + SixCdx2 + Blinker 7.0 + Protected mode
При достаточно большом количестве добавляемых записей (в интервале 150 - 500, всегда по разному) прога слетает с сообщением типа:

BLX286: 1313: General Protection Fault

либо:

DBSKIP(0) Внутренняя ошибка 1210

Отключаю от базы индексы - и всё прекрасно! Но в том-то всё и дело, что индекс нужен, чтобы не добавить то, что в базе уже есть (идёт проверка DBSEEK())...

Кто-нибудь с таким фокусом сталкивался? Как бороться?

 Отправлено: 05.11.06 13:41. Заголовок: Re:

Покажи код

 Отправлено: 05.11.06 13:55. Заголовок: Re:

цитата:

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

 Отправлено: 06.11.06 14:12. Заголовок: Dime (вроде админу :)

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

 Отправлено: 06.11.06 15:08. Заголовок: Re:

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

 Отправлено: 07.11.06 06:33. Заголовок: Re:

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 недоработано...

 Отправлено: 07.11.06 12:14. Заголовок: Re:

Ключи вроде верные ;)
Под TRIM я имел в виду RTRIM , LTRIM , ALLTRIM
Думаю Recno поможет.
Лукашевский пишет:

цитата:

Что-то в SIXCDX недоработано...

И не только в нем ;) SUV уже много раз говорил про это !

 Отправлено: 07.11.06 12:58. Заголовок: Re:

knigy->Лукашевский пишет:

цитата:

i_key = "PADR(UPPER(CHARONLY(cifrix, knigy->ISBN)), 14)"

а указывать алиас в ключе - хорошо ли? первый раз встречаю такое..

Лукашевский пишет:

цитата:

Отключаю от базы индексы - и всё прекрасно

уверен, что лучше отключить ...

Лукашевский пишет:

цитата:

достаточно большом количестве добавляемых записей (в интервале 150 - 500

... тем более при таком гиганском объёме данных

Всем привет, кстати. 7-е ноя все празднуем, надеюсь?

 Отправлено: 07.11.06 13:31. Заголовок: Re:

SergeJa пишет:

цитата:

7-е ноя все празднуем, надеюсь?

Сейчас нужны другие праздники.
Если бы не 7 ноября - жили бы мы на уровне Швеции и Финляндии. Сказка!

 Отправлено: 07.11.06 13:52. Заголовок: Re:

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

 Отправлено: 07.11.06 19:06. Заголовок: Re:

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

 Отправлено: 07.11.06 21:28. Заголовок: Re:

Лукашевский пишет:

цитата:

Буду теперь смотеть, на каком индексе прога грохается

Скорее всего на том где он самый длинный.

 Отправлено: 08.11.06 10:07. Заголовок: Диме (Вроде админу :)

Dima пишет:

цитата:

Скорее всего на том где он самый длинный.

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

 Отправлено: 08.11.06 10:19. Заголовок: Ответ SergeJa

SergeJa пишет:

цитата:

а указывать алиас в ключе - хорошо ли? первый раз встречаю такое..

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

 Отправлено: 08.11.06 11:06. Заголовок: Re:

Лукашевский пишет:

цитата:

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

сумлеваюсь в этом.

 Отправлено: 08.11.06 11:14. Заголовок: Dime (вроде админу :)

Dima пишет:

цитата:

Думаю Recno поможет.

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

 Отправлено: 08.11.06 11:15. Заголовок: Re:

Commit делаешь ?

 Отправлено: 08.11.06 11:24. Заголовок: Dime (Вроде админу :)

Dima пишет:

цитата:

сумлеваюсь в этом.

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

 Отправлено: 08.11.06 12:22. Заголовок: Re:

Лукашевский пишет:

цитата:

Странно даже, что ты с таким подходом до сих пор с этой проблемой не столкнулся!

У меня нет таких проблем. И в молодости не было. Маленький пример (могу ошибаться с синтакисом, но принцип бед должен быть ясен)

USE qqq.dbf SHARED ALIAS A1
INDEX ON A1->Fld TO qqq.NTX
USE qqq.dbf SHARED ALIAS A2
SET INDEX TO qqq.NTX

Понятно, или надо подробнее?

Лукашевский пишет:

цитата:

грохается на индексах, в ключах которых непреобразованные поля

И...?

цитата:

Вот так фокус!

А нет никакого фокуса. Увы. Читайте книжки по программированию.

 Отправлено: 08.11.06 13:57. Заголовок: Re:

SergeJa пишет:

цитата:

грохается на индексах, в ключах которых непреобразованные поля И...?

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

 Отправлено: 09.11.06 01:42. Заголовок: Dime (Вроде админу :)

Dima пишет:

цитата:

Commit делаешь ?

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

 Отправлено: 09.11.06 02:02. Заголовок: Ответ SergeJa

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 символов?

 Отправлено: 09.11.06 14:40. Заголовок: Юра

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

 Отправлено: 11.11.06 01:49. Заголовок: Всем! Всем! Всем!

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

armik пишет:

цитата:

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

Поэтому разговор об n записях теряет всяческий смысл...

 Отправлено: 11.11.06 08:34. Заголовок: Re:

Лукашевский пишет:

цитата:

Если длина индексного выражения больше 117

У меня падало и при длине 80.......
Решить проблему смог только путем уменьшения длины ключа.