Пытаюсь опять поменять атрибуты таблицы и опять ошибка, которую DB2 сама себе создает. Непонятно, IBM вообще тестирует свои продукты или нет, и почему продукты Microsoft называют глючными в таком случае...
Вот, что выдает эта DB2:
UPDATE SYSSTAT.INDEXES
SET NLEAF=1,
NLEVELS=1,
FIRSTKEYCARD=32,
FIRST2KEYCARD=-1,
FIRST3KEYCARD=-1,
FIRST4KEYCARD=-1,
FULLKEYCARD=32,
CLUSTERFACTOR=-1.000000,
CLUSTERRATIO=100,
SEQUENTIAL_PAGES=0,
DENSITY=0,
AVERAGE_SEQUENCE_GAP=0.000000,
AVERAGE_SEQUENCE_FETCH_GAP=0.000000,
AVERAGE_SEQUENCE_PAGES=0.000000,
AVERAGE_SEQUENCE_FETCH_PAGES=0.000000,
AVERAGE_RANDOM_PAGES=1.000000,
AVERAGE_RANDOM_FETCH_PAGES=0.000000,
NUMRIDS=32,
NUMRIDS_DELETED=0,
NUM_EMPTY_LEAFS=0
WHERE COLNAMES = '+PK'
AND TABNAME = 'COUNTRIES' AND TABSCHEMA = 'TEST'

Это после замены руками запятых на точки, еще вылезла беда

Кстати, я понял, в чем дело было, просто DB2 это изменение пропустила, хотя нельзя было. Я изменил атрибут, что он NULL не допускает, а в одной строке этой таблицы он был NULL. Поэтому, наверное, при изменении свойств атрибута, когда DB2 генерит кучу запросов автоматически (в том числе и тот, что я выше указал), эта ошибка и вылезла. Хотя вообще по правилам DB2 не должна даже была начать эту процедуру, если есть с NULL хотя бы одна запись.

Честно говоря, я не в курсе твоих проблем. А сколько тебе лет мальчик?
Меня интересует (это уже не к детям обращение) на самом деле данный вопрос в более широком плане, а часто ли DB2 так себя ведет и не может ли подобное привести вообще к потере данных, даже без возникновения той ошибки (в принципе, она была некритической).

Эстонский голем
ну и что и ничего в этом поучительного проблемы ребенка за комьютером

nkulikovДавай полностью опиши что ты делаешь, обсуждать отрывочные SQL операторы смысла нет.

Хорошо постараюсь. У меня есть таблица: три колонки, одна из которых в отличие от первых двух имеет свойство Nullable в значении Yes. Я его меняю на No. Таблица имеет 32 строки, только для одной из которых в этой колонке содержится NULL. Соответственно по идее DB2 не должна пропустить такое изменение, но она начинает стандартную процедуру изменения (её описывать?): первые три и пятый шаги выполняет, а в 4-ом (Restore table statistics and re-create dependent objects) происходит некритическая ошибка "FIRSTKEYCARD=32". Вот и все. В итоге я получаю измененную таблицу.

Эстонский голем
у меня праблем нету но насамом деле у тебя с DB2 ничего неполучится также как ис документумом и компани медиа руки не под то заточены

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

Речь идет о том, что по идее не должно было пройти такое изменение таблицы, если в ней есть строки, которые противоречат новым ограничениям. Или не так? Я просто не так уж и много работал с реляционками (больше с другим продуктом IBM, Lotus Notes, собственно, почему и пробую сейчас DB2, так как IBM явно переводит LN на DB2, да и с Workplace все ясно, но там выбор реляционок побольше, что приятно, так как MS SQL Server мне в свое время понравился больше, не возникало столько проблем, как с DB2, хотя тоже были, но лечились Service Pack-ами), но пока работал, у меня сложилось именно такое впечатление. Если я что-то неправильно понимаю, то поправьте, плиз. DB2 только ругнулась на FIRSTKEYCARD=32, но в целевой таблице изменение сделала на NOT NULL, написала: Load re-created table, and check data and relationship integrity. Разумеется, что строка с NULL была ликвидирована. Все изменения я делал с помощью клиента DB2. Может в нем дело? Ручками я каждый запрос сам не прописываю, для меня это ненормальная потеря времени. Если есть визуальные средства, то они должны работать, иначе, зачем они тогда? Для меня важна прежде всего возможность быстрой разработки и надежность системы.

Victor MetelitsaО какой ошибке идёт речь? Я пару раз перечитал тему и ничего не понял. Тогда я сделал таблицу сам, только не 32 записи, а 10:


сменил в CC тип поля x3 на not null. Да, IBM-еры до сих пор не пофиксили проставление запятой вместо необходимой точки (даже в FP10), но никакой "проблемы FIRSTKEYCARD=32" не заметил, равно как и "проблемы FIRSTKEYCARD=10".

Может, вы хотите, чтобы было 31 и 9 соответственно? И не надейтесь - это не ошибка, а фича, описанная в документации. Хотите правильных значений - пускайте runstats.

Вот, только что проверил это же на MS SQL Server, и эта система все сделала правильно, не допустила такого изменения таблицы.

Короче, похоже, Майкрософт ругают совершенно необоснованно, в чем и не приходилось сомневаться, вот кого надо разделить на несколько компаний так это IBM, так как они похоже давят своим монополизмом, а качество продуктов, не самое лучшее.

Хотя, возможно, что DB2 вылечится с неким паком, сейчас докачаю...