Автоинкремент в Navision

[foxsoft2005]

Итак, как мы все знаем в таблицах Navision для поля типа Integer есть замечательно поле AutoIncrement. Всем понятно, зачем оно нужно. Здесь уже много шло дискуссий на эту тему.

Опишу ситуацию из которой следует, что использование оного свойства может создать кучу проблем (рассматриваем NAV+SQL).

Итак.. Есть таблица, в которой есть поле "No." с AutoIncrement = ДА.

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

Допустим ситуацию - в таблицу вставляются 100 записей. Далее, в процессе работы (по каким-то причинам), последние 5 записей удаляются. Знающие люди понимают, что при вставке новой записи в эту таблицу через интерфейс новая запись будет иметь поле "No." равное 101, а не 96, как того хотелось бы. Т.е. "дыры" в нумерации остаются. Но это не главное.

Допустим теперь, что новый человек получил некую постановку с использованием это таблицы. Ничего не подозревая об автоинкременте, он получает последнее значение (как, например, получается последнее значение 17 таблицы при учете). Это значение в рассматриваемом примере равно как раз 96. Далее, пишется код вставки, а в результате выполнения кода вылезает ошибка SQL-сервера.

Для понимания источника ошибки рассмотрим техническую сторону вопроса:

1. При удалении строк из таблиц с автоинкрементным полем значение этого инкремента не меняется. В нашем случае оно осталось равным 101.
2. SQL сервер позволяет осуществлять принудительную вставку своего значения в инкрементные поля. Для этой цели используется спец. команда (SET IDENTITY_INSERT если быть точным).
3. Принимая во внимание пункты выше - в нашем случае поисходит следующее: при принудительном указании поля "No." Navision выполняет указанную в п.2 команду и осуществляется вставка в обход автоинкремента поля.

А где же ошибка, спросите вы? А суть в том, что для выполнения указанной в п.2 команды пользователь должен обладать минимум ролью db_owner на сервере, что для обычного пользователя системы, обычно, не есть так. Именно с этим фактом ошибка и связана.

Таким образом, получается, что если уж вы используете оное свойство поля, то должны везде его документировать как важный пункт разработки, чтобы люди, которые будут писать код после вас не попались на эту неприятную ошибку. Или не использовать автоинкремент в принципе.

Кстати, как вы думаете, почему, например в 17 таблице, поле "Entry No." не инкрементное, казалось бы - самое применение...

[romeo]

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

пс. Единственное, при записи в таблицу автоинкрементному полю надо явно присвоить 0. И фсе, что нужно для щястья.

[foxsoft2005]

Цитата:

Сообщение от romeo

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

пс. Единственное, при записи в таблицу автоинкрементному полю надо явно присвоить 0. И фсе, что нужно для щястья.

Я всего лишь поделился... А на всех не угодишь. А в случае Вашего поста нужно писать ИМХО, ведь не все такие супер-пупер одаренные..

Да и, видимо, Вы плохо читали пост.. Речь идет о баге SQL сервера из за которого работа с инкрементными полями из Навика может проблемно проходить.. Если Вы это знаете - Вы молодец, я за Вас рад. А если не знаете - так узнайте.. И обретете...

А если из всего поста Вы поняли только про "дыры" в нумерации - читайте матчасть дальше. Ничего личного, как говорится...

[foxsoft2005]

Цитата:

Вообще много о чем нужно помнить, если разработкой занимаются несколько человек.

О да, а Вы так и помните все все таблицы типы полей и нюансы работы с ним... Да?

Цитата:

Но это не значит, что от каких-либо вещей стоит отказываться.

А никто не говорил про отказ . Читайте внимательнее.

Цитата:

Автоинкрементным делают почти всегда поле, которое надо чтобы было.

Да что Вы? Это ктой-то "почти всегда" делает так? Вы только? Назовете хоть одну таблицу стандартного функционала с автоинкрементом?

Цитата:

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

Да господь с Вами.. Меня эти "дыры" тоже не интересуют Я же только об ошибке написал, а Вы сразу штыки подняли...

Цитата:

Вот так я тумаю.

Ваше право .

Цитата:

пс. Единственное, при записи в таблицу автоинкрементному полю надо явно присвоить 0. И фсе, что нужно для щястья.

P.S. И что будет? Инкремент сбросится на сервере или что?

[rmv]

FoxSoft2005 - Вы все правильно написали. Нужно только помнить о том что автоинкремент работает только в SQL версии Nav - видимо потому стандартный функционал его не использует.
К вопросу включать автоикремент или нет следует подходить очень осторожно, например автоинкремент в книгах операций на мой взгляд дело бессмысленное и опасное.
Код:
Locktable;
Find('+');
при учете используется в том числе для блокировки последней записи таблицы, пока первый пользователь учет не закончил - все остальные ждут получения последнего номера операции.
Допускаю, что Вас неустраивают блокировки и рассматриваете автоинкремент как средство для решения задачи одновременного учета несколькими пользователи. В этом случае Вам придется сильно переработать учетные кодеюниты, в частности при учете фин. журнала отказаться от формирования операций сначала во временных таблицах, с последующим сбросом в базу. Для решения задачи одновременного учета есть другие механизмы - например разделение номеров операций по диапазонам.

romeo +1.

[foxsoft2005]

Цитата:

...автоинкремент работает только в SQL версии Nav...

Кто Вам сказал такую чушь? Попробуйте намедни поработать с инкрементом в fdb.

[romeo]

Цитата:

Сообщение от FoxSoft2005

О да, а Вы так и помните все все таблицы типы полей и нюансы работы с ним... Да?

Нет, не помню. Но когда я приступаю к работе по задаче, предполагающей изменение структуры какой-либо таблицы или вставку/модификацию данных (с тем же полем автоинкремент), то я знакомлюсь с объектами. Сюда же входит и знакомство с нюансами реализации. Знать ВСЕ не является целью.

Цитата:

Сообщение от FoxSoft2005

А никто не говорил про отказ . Читайте внимательнее.

"Или не использовать автоинкремент в принципе." - это ваши слова. Надеюсь хоть их я истолковал верно.

Цитата:

Сообщение от FoxSoft2005

Да что Вы? Это ктой-то "почти всегда" делает так? Вы только? Назовете хоть одну таблицу стандартного функционала с автоинкрементом?

Честно говоря, думаю, что не только я. Называть не буду. Мне честно говоря плевать, есть ли они там или нет. Я говорю о свойстве поля Автоинкремент, которое может избавить от головной боли программиста при решении определенного рода задач.

Цитата:

Сообщение от FoxSoft2005

Да господь с Вами.. Меня эти "дыры" тоже не интересуют Я же только об ошибке написал, а Вы сразу штыки подняли...

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

Цитата:

Сообщение от FoxSoft2005

ИМХО

Мне все равно каким буквосочетанием принято обозначать свое мнение. Все, что я говорю - мое мнение.

[rmv]

Цитата:

Сообщение от FoxSoft2005

Кто Вам сказал такую чушь? Попробуйте намедни поработать с инкрементом в fdb.

Признаю . Ошибался

[artkashin]

Цитата:

Кстати, как вы думаете, почему, например в 17 таблице, поле "Entry No." не инкрементное, казалось бы - самое применение...

http://www.mibuso.com/dl.asp?FileID=958&Type=file
вот ссылка на презентацию и скрипты по дедлокам и блокировкам. В презентации на 15 странице, чел советует использовать поля "Entry No." с типом автоинкремент для учетных таблиц.
А стандартный код - просто он был написан очень давно, и следуя старой доброй традиции - под автоинкремент просто не оптимизировался.

Цитата:

Нужно только помнить о том что автоинкремент работает только в SQL версии Nav - видимо потому стандартный функционал его не использует.

Нет, он работает и в Native.

Цитата:

2. SQL сервер позволяет осуществлять принудительную вставку своего значения в инкрементные поля. Для этой цели используется спец. команда
...
Таким образом, получается, что если уж вы используете оное свойство поля, то должны везде его документировать как важный пункт разработки, чтобы люди, которые будут писать код после вас не попались на эту неприятную ошибку. Или не использовать автоинкремент в принципе.

Ну, а чем автоинкремент по вашему отличается от остальных особенностей системы, например, AutoSplitKey или значений по умолчанию при инициализации переменной? Если программист написал неправильный код, то значит надо исправить код, а не раздавать права владельца и устанавливать свойства сервера для принудительной вставки в АВТОИНКРЕМЕНТНОЕ поле. Мыши плакали и кололись, кололись и плакали. Но продолжали есть кактусы.

[foxsoft2005]

Цитата:

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

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


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

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

Далее, в Вашем опусе на мой "забавный пост" Вы сказали, что инкрементное поле, дескать, это никому не нужное число. Позвольте с Вами не согласиться.. С каких пор ПК (а ведь изначально, в SQL, такие поля именно для ПК используются) стал никчемным и ненужным полем?

[romeo]

Цитата:

Сообщение от FoxSoft2005

Вы сказали, что инкрементное поле, дескать, это никому не нужное число. Позвольте с Вами не согласиться.. С каких пор ПК (а ведь изначально, в SQL, такие поля именно для ПК используются) стал никчемным и ненужным полем?

Блина ) Уважаемый, я не против первичных ключей. Я лишь говорю о том, что в данном случае выбирается вариант, при котором ЗНАЧЕНИЕ первичного ключа никого не должно волновать. Генерится оно себе и генерится. И лишь одну вещь надо помнить при вставке данных в такую таблицу - НОЛЬ принудительно присвоить в поле ПК.

пс. Задело, я вижу, вас слово "забавный" )))) Забавно. Ну лексикон у меня такой.
ппс. А сейчас, ВНИМАНИЕ, я выдаю желаемую вами ОСь на пост - уважаемый FoxSoft2005, спасибо за столь нужное замечание по работе с автоинкрементными полями в Навижен.

[foxsoft2005]

Цитата:

Сообщение от romeo

Блина ) Уважаемый, я не против первичных ключей. Я лишь говорю о том, что в данном случае выбирается вариант, при котором ЗНАЧЕНИЕ первичного ключа никого не должно волновать. Генерится оно себе и генерится. И лишь одну вещь надо помнить при вставке данных в такую таблицу - НОЛЬ принудительно присвоить в поле ПК.

пс. Задело, я вижу, вас слово "забавный" )))) Забавно. Ну лексикон у меня такой.
ппс. А сейчас, ВНИМАНИЕ, я выдаю желаемую вами ОСь на пост - уважаемый FoxSoft2005, спасибо за столь нужное замечание по работе с автоинкрементными полями в Навижен.

Да нет, что Вы что Вы .. Меня не задело.. Я просто пытался соответствовать лексикону человека, с коим я спорю.. Не более не менее .

Я был уверен, что многие знаю об этом баге, просто не нашел его на форуме, вот и решил написать .

Так что "мир, дружба, жвачка"

[SVG]

О, придумал! Давайте откажемся от вычисляемых полей!
Ведь новенький программист не знает, что поле вычислемое, и будет
получать там всегда 0!


А у FoxSoft2005 плохое настроение, что он так реагирует неадекватно? Критические дни?
"читайте матчасть дальше"
"Кто Вам сказал такую чушь?"
"не все такие супер-пупер одаренные"

Ничего личного (с) FoxSoft2005

Нет никакой "баги SQL сервера", строгая и стройная логика.
То, что иногда люди не знают, что поле в таблице автоинкрементное - не так страшно,
один раз наступив на это, запомнят и будут знать, никаких проблем.

[foxsoft2005]

Цитата:

Сообщение от SVG

...
Нет никакой "баги SQL сервера", строгая и стройная логика.
...

Да что Вы? Уверены? Точно точно уверены?

http://support.microsoft.com/kb/302621

А ведь именно этото код ошибки выдается...

P.S. Конечно понятно, что слово BUG и Майкрософта уже ассоциируется с FEATURE.. Но все же!

P.S.S. Правда речь там идет о не о конкретно инкременте - но о более общей команде SET.

[SVG]

"Насчет использования инкремента в принципе - да, я против, так как считаю инкремент граблями другого разработчика"
Т.е. вопреки всем рекоммендациям вы настаиваете на архаичном поиске последнего значения? ))))
Это во-первых медленно, во-вторых ведет к блокировкам, в-третьих требует нескольких ненужных минут программирования.
И для чего?
Если вам так мешают автоинкременты, используйте CLEAR(Record) вместо Record.INIT
и вы навсегда забудете об этой проблеме!!!

[foxsoft2005]

Цитата:

Сообщение от SVG

О, придумал! Давайте откажемся от вычисляемых полей!
Ведь новенький программист не знает, что поле вычислемое, и будет
получать там всегда 0!


А у FoxSoft2005 плохое настроение, что он так реагирует неадекватно? Критические дни?
"читайте матчасть дальше"
"Кто Вам сказал такую чушь?"
"не все такие супер-пупер одаренные"

Ничего личного (с) FoxSoft2005

Нет никакой "баги SQL сервера", строгая и стройная логика.
То, что иногда люди не знают, что поле в таблице автоинкрементное - не так страшно,
один раз наступив на это, запомнят и будут знать, никаких проблем.

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

Правда вот передергивать не стоит ...

P.S. Я вот поражаюсь... Уважаемый, Вы, например, всегда были классным разработчиком (уверен, что это так!!) навижн? Прямо родились таковым? Или этот форум только для ассов?

[SVG]

"http://support.microsoft.com/kb/302621"
Здесь речь о BULK INSERT, при чем тут вставка единичной записи в таблицу?

Этта... Я не только не родился классным программистом, я вам больше скажу )))))
Когда я впервые столкнулся с такой фигней - вставляю запись в таблицу, а оно мне - не могу вставить
Я ПРОСТО ЗАМАНАЛСЯ ИСКАТЬ почему эта дрянь ругается, реально ЗАМАНАЛСЯ, убил минут 15 точно
А потом увидел автоинкремент
Запомнил, и больше инкремент проблем не вызывает )

[rmv]

Цитата:

Сообщение от SVG

"Насчет использования инкремента в принципе - да, я против, так как считаю инкремент граблями другого разработчика"
Т.е. вопреки всем рекоммендациям вы настаиваете на архаичном поиске последнего значения? ))))
Это во-первых медленно, во-вторых ведет к блокировкам, в-третьих требует нескольких ненужных минут программирования.
И для чего?
Если вам так мешают автоинкременты, используйте CLEAR(Record) вместо Record.INIT
и вы навсегда забудете об этой проблеме!!!

Ну а в четвертых блокировки не всегда зло. Особенно при учете.
Выставьте автоинкремент на 17 таблице, перепишите код в 12 кодеюните для одновременного учета.. и готовтесь ловить фантомы.
Навижн не позволяет явно управлять ни уровнем блокировки ни уровнем изоляции.

PS. Если Вы предложите другой способ гарантирования блокирования последней записи, кроме как
Locktable;
Find('+')
с удовольствием его проанализирую.

[SVG]

rmv
Не пробовал, а на слово не поверю )
Ну даже ладно, пусть блокировки при учете - это не зло, пусть... Гыгы...
Речь не об учете ) А об автоинкременте в целом )

ЗЫ какой-то спор ни о чем..

[romeo]

Цитата:

Сообщение от FoxSoft2005

Прямо родились таковым? Или этот форум только для ассов?

В своем посте вы предлагаете отказаться от одной из возможностей навижен, которая знающим людям кажется вполне удобной и нужной. Зачем это новичку? Надеюсь люди вполне адекватны, чтобы осторожно следовать советам на форуме. Как здесь уже сказали, есть еще одно "замечательное" свойство AutoSplitKey. Пользователю вообще не понятно, почему происходит ошибка, если он поменял порядок записей в субформе и хочет вставить еще одну запись. Много есть неприятностей в нави. Но это нави. И это главный нюанс нашей работы.