iBase.ru Forum

(FB1.52, IBExpert)
Помогите,
-------------
CREATE TABLE TABLE_1 (
ID INTEGER NOT NULL,
NAME INTEGER);

alter table TABLE_1 add constraint PK_TABLE_1 primary key (ID);
-------------
Запись правильна, а тем не менее при попытке ее запуска выдается следующее:

Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 24, char -1.
ALTER.

То есть индекс устанавливаться не желает, хотя в системных таблицах вообще нет никаких индексов ссылающихся таблу ITOGATTESTAT и таблы такой нет.

2я непонятка попытка создать таблу вручную завершается успешно, НО несмотря на то что формируется код точно такой как я уже указал и имя у новосозданного индекса должно быть PK_ITOGATTESTAT, в реальности формируется индекс с именем типа RDB$PRIMARYxxx.

Вот так ошибок нет, создается и табла и индекс:
CREATE TABLE table_1 (
ID INTEGER NOT NULL CONSTRAINT PK_table_1 PRIMARY KEY,
NAME VARCHAR(100) );

только индекс все равно не PK_table_1, а RDB$PRIMARYxxx.
А хотелось бы, чтобы были более вразумительные имена у индексов

Два стейтмента надо выполнять в скриптере, а не в обычном SQL-редакторе.

Хорошо, а как быть с именованием первичного индекса?

тебе же объясняют - два оператора в SQL Editor надо выполнять по очереди. Или заселектить один, нажать "выполнить" и Commit, затем заселектить второй, и опять "выполнить" и commit.

вразумительные имена индексов должны быть что при создании ПК в create table, что при alter table, если база в третьем диалекте и ты пишешь constraint consr_name primary key...

kdv писал(а):тебе же объясняют - два оператора в SQL Editor надо выполнять по очереди. Или заселектить один, нажать "выполнить" и Commit, затем заселектить второй, и опять "выполнить" и commit.

вразумительные имена индексов должны быть что при создании ПК в create table, что при alter table, если база в третьем диалекте и ты пишешь constraint consr_name primary key...

- я выполняю команды в редакторе скриптов. Так список команд теперь не выдает ошибки. А вот другой вопрос остался ИМЕНА новосозданных ИНДЕКСОВ все еще RDB$PRIMARYxxx. база в третьем диалекте и я пишу:
CREATE TABLE TABLE_1 (
ID INTEGER NOT NULL,
NAME INTEGER);

alter table TABLE_1 add constraint PK_TABLE_1 primary key (ID);
Вроде все правильно...

у меня не воспроизводится. база ODS 10.1, индексы соответствуют именам constraint.

kdv писал(а):у меня не воспроизводится. база ODS 10.1, индексы соответствуют именам constraint.

Может есть какие-нибудь подозрения из-за чего индексы не принимают указанных имен? И еще, что такое база ODS 10.1 и где это можно посмотреть, если не секрет?
Кстати, у меня раньше индексы тоже принимали указанные имена, но не могу сказать после какого момента это изменилось. Я недавно перешел с FB 1.5 > 1.52 и IBExpert2004>IBExpert2005, если важно...

ODS - gstat -h или IBAnalyst, и в www.ibase.ru/devinfo/prevver.htm

Благодарю, сейчас почитаем

как я понял, если я создаю базу в FB1.5, то ее версия будет ODS 10.1 ?
В таком случае у меня такая же версия
А не может быть недоразумений, из-за того что установлен IB6.5 и FB1.5 ?

базу в чем создавал или ресторил? в IB 6.5 или FB 1.5?

kdv писал(а):базу в чем создавал или ресторил? в IB 6.5 или FB 1.5?

- FB 1.5
ресторил - восстанавливал? Тоже FB 1.5

стоп-стоп!!!
надо не а то есть, ПК или UNIQUE создавать не "по месту", а в конце create table. я уж и не помню, когда таким синтаксисом пользовался.

Кстати, только что проверил - все едино. FB 1.5, база ODS 10.1, третий диалект. Оба оператора приводят к созданию индекса PK_TABLE_1 по первичному ключу. Никаких RDB$PRIMARYxx. Могу картинку из IBExpert прислать.

Понял что дело в глобальном - снес IB6.5 и FB1.5 и переставил FB1.5 - теперь, блин работает как нада "№,%?;№
Спасибо за ответы

вот не надо. у меня эксперимент проходил под FB 1.5 с gds32.dll от IB 7.5. Где-то ты сам накосячил. Сам понимаешь - тут все примитивно. Есть клиент, и есть сервер. Больше нету ничего. У меня на машине стоят вообще IB 6, IB 6.5, IB 7.1, IB 7.5, FB 1.0, 1.5, 2.0 - и ничего. никто никому не мешает.

kdv писал(а):вот не надо. у меня эксперимент проходил под FB 1.5 с gds32.dll от IB 7.5.

Да там дело не в gds-ке было. Он в базу лазал вообще то одним сервером, то другим и сам толком не знал, когда у него какой был запущен. Имхо там вообще полная каша, ей бы b/r сейчас сделать да потом триггера с процедурами перекомпилить все.

kdv писал(а):вот не надо. у меня эксперимент проходил под FB 1.5 с gds32.dll от IB 7.5. Где-то ты сам накосячил. Сам понимаешь - тут все примитивно. Есть клиент, и есть сервер. Больше нету ничего. У меня на машине стоят вообще IB 6, IB 6.5, IB 7.1, IB 7.5, FB 1.0, 1.5, 2.0 - и ничего. никто никому не мешает.

А я не утверждаю, что они друг другу мешают, возможно FB коряво встал в первый раз при инсталяции...

Merlin писал(а):

kdv писал(а):вот не надо. у меня эксперимент проходил под FB 1.5 с gds32.dll от IB 7.5.

Да там дело не в gds-ке было. Он в базу лазал вообще то одним сервером, то другим и сам толком не знал, когда у него какой был запущен. Имхо там вообще полная каша, ей бы b/r сейчас сделать да потом триггера с процедурами перекомпилить все.

насчет того что я вперемешку то под одним сервером лазил то под другим неверная предпосылка, через IB6.5 я стал лазить от безысходности, а до этого ни-ни
К тому же после переустановки FB в той же самой базе все стало ок. Так что дело не в каше

не смеши. что там может "коряво встать", если там всего-то на самом деле два файла. меня всегда умиляла фраза "переставил - заработало", в отношении IB/FB. нет там ничего такого, что могло бы не заработать. Он или не работает вообще, или работает. Почитай faq по установке, убедишься.