Доброе время суток!

при попытке вызвать скрипт из IBExpert



на строке SELECT gen_id( "GID_MTG", -gen_id( "GID_MTG", 0 ) ) FROM RDB$DATABASE;
вываливает "Token unknown"
Генератор "GID_MTG" в этот момент в базе присутствует, поясните почему?

wadman

Чем нормальный вариант не подходит?
его только при отсутствии записей в таблице надо выполнить

Симонов Денис,

спасибо

Симонов Денис,

туплю походу
так


тоже ругается "Token unknown"
заменяю GEN_ID(:gen_name, -GEN_ID(:gen_name, 0 )) на что то другое проходит без проблем.
FireBird 2.5, IBExpert 2013.2.15.1

m7mMikhail Tchervonenko,

GEN_ID()

на что Вы намекаете? что минус нельзя использовать?
дело в том что конструкчия вида


в сети многократно приводится ка пример обнуления счетчика.
Если можн поконкретнее в чем причина.

Симонов Денис,

ага, теперь понятно, спасибо

Гаджимурадов Рустам,

спасибо

я только разбираюсь с FireBird
немного непривычно после MSSQL и MySQL

wadmanMikhail Tchervonenkoв сети многократно приводится ка пример обнуления счетчика.
Где "в сети"?

тут и тут

Гаджимурадов РустамMikhail Tchervonenko> я только разбираюсь с FireBird
> немного непривычно после MSSQL и MySQL

Так в TSQL то же самое, как и в PSQL.


ну насчет генераторов я бы так не сказал

Dimitry SibiryakovMikhail Tchervonenkoнемного непривычно после MSSQL и MySQL
И часто ты в MS SQL обнулял IDENTITY?..

я автоинкрементами вообще не пользовался (за редким исключением) и всегда считал их злом. Здесь просто проект в котором уже они везде задействованы, приходится пользовать.

кстати обнуляю я их не в программе а в скрипте который генерирует таблицы.

wadmanMikhail Tchervonenkoкстати обнуляю я их не в программе а в скрипте который генерирует таблицы.
Почему этот-же скрипт не (пере)создает генераторы для создаваемых таблиц?
тут согласно внутренней политике все изменения в базе ведутся через скрипты. Если в базе создаётся блок по смыслу связанных таблиц то до первого релиза программы работающей с этим блоком удобно иметь скрипт который создаёт таблицы (если они не созданы ещё), копирует в них какие то данные и изменяет структуру таблиц в хронологическом порядке. При этом желательно если в процессе тестирования какие то данные добавились в таблицы не удалять их без особой нужды (это к вопросу почему просто не пересоздать генераторы). После выхода первого релиза, под каждый новый релиз, создаётся свой скрипт который вносит уже только изменения в структуру таблиц и если необходимо добавляет новые. Это очень удобно если разработку надо вести и вне пределов фирмы, напр, дома на ноуте. Зачекал скрипт из svn, накатил и получил последний вариант структуры базы. Безусловно иногда и дамп базы накатить приходится но это времязатратно и не всегда необходимо.

А индексы привык использовать либо из комбинации полей, и только если нужна порядковая нумерация автоинкремент. В некоторых случаях удобны GUID подобные индексы, особенно если нужно уникальность поля не только в рамках таблицы но и в рамбках базы или многих баз. К такому GUID удобно привязывать все (логгирование, блокировки итп вещи если они реализовываются не родными средствами сервера баз данных). Автоинкремент плох, с моей точки зрения, дополнительными проблеммами при синхронизации или слиянии данных. Думаю эти проблеммы и без меня всем хорошо известны. Вот собственно и все.

Симонов ДенисMikhail Tchervonenko,

IBExpert прекрасно умеет генерировать скрипт обновления при сравнении как с контрольной БД, так и со скриптом. Так что напрасно вы себя так мучаете.

Тут это отчасти с документированием связано итп Да и не я правила устанавливаю (пока).
Достоинство скрипта в том что он может и с нуля все сделать и интеллектуально по задуманной логике, на мой испорченный взгляд удобно. Конечно не так как это в Visual Studio реализовано (см. проект базы), но хоть что то. Если бы у FireBird было что то что позволяет напрямую хранить структуру базы и скрипты в SVN как это реализовано в продуктах для MSSQL то было бы намного удобнее.

Вообще надо идею подкинуть разработчикам IBExpert сделать интеграцию с svn и git. Было бы удобно.

PEAKTOPMikhail TchervonenkoАвтоинкремент плох, с моей точки зрения, дополнительными проблеммами при синхронизации или слиянии данных.

у ERP-шников есть правило: первичный ключ (ID-записи) не должен нести НИКАКОЙ информации об объекте в базе.
еще раз: НИКАКОЙ! это просто идентификатор записи.

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

а проблемы синхронизации решаются путем дополнительной таблицы, в которой есть домены:

Да, примерно так на MsSQL и делали всегда. Единственное в качестве первичного ключа всегда пользовал GUID что позволяло обойтись без вышеописанной таблицы.

kdvMikhail Tchervonenko Если бы у FireBird было что то что позволяет напрямую хранить структуру базы и скрипты в SVN
isql -x и закидывай в SVN.
Такое тоже используем.
Но только что б потом сравнить что изменили.