Доброго времени суток,
Столкнулся со странной проблемой - приложение написанное на 4 делфях вдруг стало выдавать ошибку "Size mismatch for field'RDB$RELATION_NAME' EXPECTING :31 ACTUAL :93" при попытке изменить путь к базе данных ... Странность в том что исходники эти лежали несколько месяцев, а до этого никаких подобных ошшибок не было! Ругается на системные поля файрбердовской базы которые я так же пальцем не трогал (вернее саму базу я редактировал, но в системные поля и таблицы не лез). Вместе с этим так же появилась ошибка базы о том что она уже открыта при запуске программы. Разумеется, исправляется это легко - выставлением закрытого состояния объекта DB... но тут снова 1я засада - редактировать то я его не могу из за ошибки...

Гуглил проблему, нашел всего 1 упоминание и то о том что это косяк патчка к 7 делфям...но у меня то 4...

Буду рад любым подсказкам.

backup/restore базы проходят без ошибок?

в проге статический экземпляр поля.длина его 31 символ.
а в базе стало 93. хотя раньше было 31.

Закономерное "по башке" вследствие использования Table-технологии.

> backup/restore базы проходят без ошибок?

Это тестовые базы (их 3 от разных дат, но эффект на всех 1 и тот же) и бек\рестор я им если честно не делал, завтра попробую... хоть и маловероятно что все разом побились.


> в проге статический экземпляр поля.длина его 31 символ.а
> в базе стало 93. хотя раньше было 31.


Да, это ясно из ошибки, но повторюсь - не редактировал я системные поля!
Могло ли это как то произойти при редактировании\добавлении обычных таблиц\полей\процедур?
Кстати я уже пытался их изменить (т.е. задать вместо 31 длину 93) - база не дает.

не редактировал я системные поля!

ну тогда чего переволновался так?
ошибка вылезла?
так это оптический обман. забей.
ты же ничего не изменял.

/* а проверить что там реально не догадался */

т.е. задать вместо 31 длину 93) - база не дает.


вместо тридцати одного в базе уже и так лежит девяносто три.
чего она тебе еще -то должна дать?

Вообще то наоборот, база расчитана на 31 максимум, а он путается засунуть туда 93

>Могло ли это как то произойти при редактировании\добавлении обычных >таблиц\полей\процедур

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

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

Перед написанием программ (и в процесее тоже) надо читать хоть что-нибудь кроме Фаронова.
Это в-третьих

> Медвежонок Пятачок ©   (19.07.12 17:52) [5]
> не редактировал я системные поля!ну тогда чего переволновался
> так?ошибка вылезла?так это оптический обман. забей.ты же
> ничего не изменял./* а проверить что там реально не догадался
> */



> вместо тридцати одного в базе уже и так лежит девяносто
> три.чего она тебе еще -то должна дать?


> Anatoly Podgoretsky ©   (19.07.12 18:57) [7]
> Вообще то наоборот, база расчитана на 31 максимум, а он
> путается засунуть туда 93

Анатолий совершенно прав, в базе 31 - это я проверил 1м делом.

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


Дело в том что эту программу писал 1 человек, а потом доробатывало еще человека 3 до меня ну и + теперь я сам...

На счет нештатных ситуаций - есть фибовский обработчик ошибок, но как я уже говорил, именно эта ошибка возникла недавно и ее нет в нем. Добавить туда ошибку что "база уже открыта", конечно, можно, но зачем? Я уверен, что когда удастся побороть несоответствие полей исчезнет и она.

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

Анатолий совершенно прав, в базе 31 - это я проверил 1м делом.

Ну и чего?
Какая разница?
Если до тебя до сих пор не дошло, что в базе одна длина поля, а в программе - другая.
Ума хватает только на бубнение "я ничего не менял"

Кроме того!
Я тебе могу найти сто полей с такой длиной (31) и заявить что ты ошибаешься.
А в сто первом поле на которое и идет реальная ругань - будет 93.

Или.

Найду в базе поле длиной 31 символ и в программе найду ему же соответствующее поле длиной 31 символ. И буду талдычить, а как же так? Я же ничего не менял и длины совпадают?
А в другом месте программы - есть еще один экземпляр этого же поля с другой длиной и при инициализации этого датасета и происходит ошибка.
Но мы же умные. Мы материалисты. Мы же мля ничего не меняли уверены мы.

Удалено модератором

Удалено модератором

> PEAKTOP ©   (21.07.12 01:38) [13]
>
> Удалено модератором


Афигеть.
Делфимастер стал еще и анально-огороженным.