Автор | Сообщение |
|
| |
Пост N: 40
Зарегистрирован: 08.04.06
|
|
Отправлено: 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())... Кто-нибудь с таким фокусом сталкивался? Как бороться?
|
|
|
Ответов - 24
, стр:
1
2
All
[только новые]
|
|
|
| |
Пост N: 429
Зарегистрирован: 17.05.05
|
|
Отправлено: 05.11.06 13:41. Заголовок: Re:
Покажи код
|
|
|
|
| |
Пост N: 430
Зарегистрирован: 17.05.05
|
|
Отправлено: 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
|
|
|
|
| |
Пост N: 41
Зарегистрирован: 08.04.06
|
|
Отправлено: 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ами всё было путём.
|
|
|
|
| |
Пост N: 432
Зарегистрирован: 17.05.05
|
|
Отправлено: 06.11.06 15:08. Заголовок: Re:
Покажи ключ в INDEX , небось TRIM там ? :) если нет , должно помочь +str(recno(),12) или типа того. сам попадал на эти грабли.
|
|
|
|
| |
Пост N: 42
Зарегистрирован: 08.04.06
|
|
Отправлено: 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 недоработано...
|
|
|
|
| |
Пост N: 433
Зарегистрирован: 17.05.05
|
|
Отправлено: 07.11.06 12:14. Заголовок: Re:
Ключи вроде верные ;) Под TRIM я имел в виду RTRIM , LTRIM , ALLTRIM Думаю Recno поможет. Лукашевский пишет: цитата: | Что-то в SIXCDX недоработано... |
| И не только в нем ;) SUV уже много раз говорил про это !
|
|
|
|
| |
Пост N: 75
Зарегистрирован: 28.06.05
|
|
Отправлено: 07.11.06 12:58. Заголовок: Re:
knigy->Лукашевский пишет: цитата: | i_key = "PADR(UPPER(CHARONLY(cifrix, knigy->ISBN)), 14)" |
| а указывать алиас в ключе - хорошо ли? первый раз встречаю такое.. Лукашевский пишет: цитата: | Отключаю от базы индексы - и всё прекрасно |
| уверен, что лучше отключить ... Лукашевский пишет: цитата: | достаточно большом количестве добавляемых записей (в интервале 150 - 500 |
| ... тем более при таком гиганском объёме данных Всем привет, кстати. 7-е ноя все празднуем, надеюсь?
|
|
|
|
| |
Пост N: 61
Зарегистрирован: 06.06.06
|
|
Отправлено: 07.11.06 13:31. Заголовок: Re:
SergeJa пишет: цитата: | 7-е ноя все празднуем, надеюсь? |
| Сейчас нужны другие праздники. Если бы не 7 ноября - жили бы мы на уровне Швеции и Финляндии. Сказка!
|
|
|
|
| |
Пост N: 76
Зарегистрирован: 28.06.05
|
|
Отправлено: 07.11.06 13:52. Заголовок: Re:
В Швеции не было революций (а они на пустом месте не появляются). Войн (к революциям приводящим). Идиотов/гадов/предателей-правителей (у нас - с НиколаяII - такие). так что сравнение не катит. А праздновать 4-е ноября - нелепость. И оффтопик :)
|
|
|
|
| Администратор
|
Пост N: 384
Зарегистрирован: 23.05.05
|
|
Отправлено: 07.11.06 19:06. Заголовок: Re:
А как же, празднуем :) У нас 4 ноября нет, зато есть свой маразм
|
|
|
|
| |
Пост N: 434
Зарегистрирован: 17.05.05
|
|
Отправлено: 07.11.06 21:28. Заголовок: Re:
Лукашевский пишет: цитата: | Буду теперь смотеть, на каком индексе прога грохается |
| Скорее всего на том где он самый длинный.
|
|
|
|
|
| |
Пост N: 43
Зарегистрирован: 08.04.06
|
|
Отправлено: 08.11.06 10:07. Заголовок: Диме (Вроде админу :)
Dima пишет: цитата: | Скорее всего на том где он самый длинный. |
| В каком-то смысле именно так, но думаю, что длина индексного выражения не главное - самое смешное оказалось, что прога грохается на индексах, в ключах которых непреобразованные поля (т.е. "knigy->avtor + knigy->nazv" и "knigy->nazv + knigy->avtor")! Вот так фокус!
|
|
|
|
| |
Пост N: 44
Зарегистрирован: 08.04.06
|
|
Отправлено: 08.11.06 10:19. Заголовок: Ответ SergeJa
SergeJa пишет: цитата: | а указывать алиас в ключе - хорошо ли? первый раз встречаю такое.. |
| Это-то как раз абсолютно нормально! В молодости я пытался делать индексы без алиасов в ключевом выражении, но столкнулся с тем, что если переходишь SELECTом к другой базе, в которой есть точно такие же по наименованию поля (как и в ключе прежней базы), индексы в прежней базе начинают изменяться в соответствии с содержимым полей текущей базы! :-( Странно даже, что ты с таким подходом до сих пор с этой проблемой не столкнулся!
|
|
|
|
| |
Пост N: 435
Зарегистрирован: 17.05.05
|
|
Отправлено: 08.11.06 11:06. Заголовок: Re:
Лукашевский пишет: цитата: | индексы в прежней базе начинают изменяться в соответствии с содержимым полей текущей базы! :-( |
| сумлеваюсь в этом.
|
|
|
|
| |
Пост N: 45
Зарегистрирован: 08.04.06
|
|
Отправлено: 08.11.06 11:14. Заголовок: Dime (вроде админу :)
Dima пишет: К сожалению, не помог... Не помог, как ни странно, и PADR() тоже... :( Буду дальше экспериментировать.
|
|
|
|
| |
Пост N: 438
Зарегистрирован: 17.05.05
|
|
Отправлено: 08.11.06 11:15. Заголовок: Re:
Commit делаешь ?
|
|
|
|
| |
Пост N: 46
Зарегистрирован: 08.04.06
|
|
Отправлено: 08.11.06 11:24. Заголовок: Dime (Вроде админу :)
Dima пишет: Можешь сумлеваться сколько угодно, а так действительно было и у меня с тех самых пор ни одного поля в ключевом выражении без алиаса нет... Было оно, правда, в 5.01 на NTXах - может, CDXы В ЭТОМ СМЫСЛЕ изменяются корректнее...
|
|
|
|
| |
Пост N: 77
Зарегистрирован: 28.06.05
|
|
Отправлено: 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 Понятно, или надо подробнее? Лукашевский пишет: цитата: | грохается на индексах, в ключах которых непреобразованные поля |
| И...? А нет никакого фокуса. Увы. Читайте книжки по программированию.
|
|
|
|
| |
Пост N: 440
Зарегистрирован: 17.05.05
|
|
Отправлено: 08.11.06 13:57. Заголовок: Re:
SergeJa пишет: цитата: | грохается на индексах, в ключах которых непреобразованные поля И...? |
| На самом деле такая проблема существует. У меня падало при добавлении в базу около 1000 записей или около того и тоже вот с такими длинными ключами. Str(recno()) не спасло. Уменьшил длину ключа и пока работает. Тож самое не падает под ADS , в SIX падает или может упасть.
|
|
|
|
| |
Пост N: 47
Зарегистрирован: 08.04.06
|
|
Отправлено: 09.11.06 01:42. Заголовок: Dime (Вроде админу :)
Dima пишет: Это внутри append from? Нет, в принципе, наверное, можно засунуть его в условие FOR и делать Commit после принятия какого-то кол-ва записей, но фишка оказалась ещё и в том, что прога рушится после принятия 150-500 записей - это, оказалось, частный случай, а в общем случае не принимается НИ ОДНОЙ записи! Обрушение идёт сразу же! Как пример я взял совершенно пустую базу (но со всеми теми же индексами) и при попытке добавления к ней записей из другого файла по append from - сразу вылет с ошибкой BLX286: 1313: exception error 0D: General protection fault И весь фокус в том, что в принимаемом файле поле NAZV шириной 70, а в принимающей базе - 90! Когда делаю ширину одинаковой (70) - процесс проходит беспроблемно!
|
|
|
Ответов - 24
, стр:
1
2
All
[только новые]
|
|