Как в таблице Access ключевое, автоинкрементное поле (Счётчик)&#133

← →
Knight © (2007-04-10 23:54) [0]

&#133 могло сбросится в ноль? И как можно его вернуть назад на путь истинный?

← →
Knight © (2007-04-11 00:18) [1]

Как вернуть нашёл&#133 добавил запись со следующим значением счётчика&#133 оно ругнулось, но запись добавилась&#133 и счётчик пошёл дальше. Завтра попробую на рабочей база.

Но вопрос таки&#133 как такое могло произойти :/

← →
sniknik © (2007-04-11 01:11) [2]

> добавил запись со следующим значением счётчика… оно ругнулось, но запись добавилась…
добавь тем же образом 0

← →
Германн © (2007-04-11 01:30) [3]

> sniknik © (11.04.07 01:11) [2]
>
> > добавил запись со следующим значением счётчика… оно ругнулось,
> но запись добавилась…
> добавь тем же образом 0
>

Неужели Access допускает такое "брутальное" обращение с "автоинкрементным полем"?

← →
Иксик © (2007-04-11 03:45) [4]

Кто-то сделал Fix and Repair Database?

← →
sniknik © (2007-04-11 09:14) [5]

> Неужели Access допускает такое "брутальное" обращение с "автоинкрементным полем"?
не знаю как он добавлял... но "ручной" insert в аксесс работает в режиме SET IDENTITY_INSERT ... ON (по типу MSSQL), т.е. при нужде можно вставить свое значение.
и это вполне нормально если учесть что пакетов комманд аксесс не позволяет (нельзя выполнить SET IDENTITY_INSERT перед собственно запросом, даже если бы была), самой такой команды переопределения поведения нет, а вставлять не автоинкрементные значения в автоинкремент всетаки нужно, и довольно часто (например получение копии таблицы из другой базы).

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

и потом, сам счетчик в таких случаях не страдает, значение в поле меняется а счетчик нет, но есть варианты когда и он пересчитывается... тот же > [4] Repair Database и вроде по последнему добавленному.
т.е. при паре ошибок со стороны программиста вполне допустимый результат, первая сделать инсерт с нулем в то поле которое при нормальной работе не трогается вообще, и вторая тутже сделать pack&repair... ошибка в том, что ее как знаю некоторые делают чуть ли не после каждой операции, сколько бы не предупреждали. размер экономят...

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

← →
Knight © (2007-04-11 10:34) [6]

Случилось это в учётной музейной проге. Написана московской фирмой в Access... Всё более-менее работало, потом перестали добавляться описания предметов (никто ничего не делал в плане работы с базой напрямую). Зарез в сам Access минуя запуск интерфейса. попробовал добавить запись вручную прямо в таблицу, он мне выдал, что номер в индексном поле не уникальный... оказалось, что вместо 4 тысячи какого-то, он генерит в 536 и т.д. учитывая, что сообщили мне об этом только спустя пару недель, то можно предположить, что они уже от нуля столько нагнали, энергии у людей дофига, ещё бы в нужное русло :)

Не ожидал я таких приколов от автоинкремента. Считал, что он идёт по возрастающей без всяких откатом :(

> Написана московской фирмой в Access...
т.е. посмотреть как именно добавляется нельзя? жаль.

> Не ожидал я таких приколов от автоинкремента. Считал, что он идёт по возрастающей без всяких откатом :(
он так и идет, если не делать ничего специально... возможную последовательность я описал (даже 2). ну, и т.к. посмотреть добавление не удасться то проверь то что можно -> версия базы? в меню офиса XP/2003/?? "сервис"."служебные программы"."преобразовать базу данных" дизейбленное значение текущее. я практически уверен у тебя будет аксесс 97.

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

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

вот, пример того как можно воссоздать ситуацию
CREATE TABLE TstTable (ID INT Identity(10, 1), Name VarChar(30))
INSERT INTO TstTable (Name) VALUES ("10")
INSERT INTO TstTable (Name) VALUES ("11")
ALTER TABLE TstTable ALTER COLUMN ID INT Identity(0, 1) PRIMARY KEY
INSERT INTO TstTable (Name) VALUES ("0")
...
и т.д.
на десятом будет, глюк, естественно это не глюк аксесс, это мои действия... и эти действия не эксклюзив... видел чтото подобное делали для убирания "дырок", код там естественно был позапутаней но смысл похож, искали "дырку" и устанавливали счетчик не нее, следующее добавление ее заполняло... не надо быть семи пядей во лбу, чтобы понять, любая нестыковка, сбой в расчетах собьет нормальную работу... (что и произошло. разовая ошибка (занятость другим юзером), сбой между двумя операциями, необработанная естественно, куда уж, все усилия пошли не туда;(, и база рухнула.)

При установке говорили, что нумерация записей сквозная, т.е. никаких заполнений нет... потому и не понял откуда это вылезло. Разработано и работало на Office 2000. Надо написать разработчикам. Спасибо за варианты :)

Как в таблице Access ключевое, автоинкрементное поле (Счётчик)&amp;#133 Найти похожие ветки

Как в таблице Access ключевое, автоинкрементное поле (Счётчик)&#133 Найти похожие ветки