|
|
|
| столкнутся вчера... потратил 2 часа на поиски решения... может у меня не все фиксы стоят какие надо?
последовательность действий для получения эффекта.
1. создаем таблицу в которой id будет счетчик (остальные поля не важны)
2. добавляем руками в таблицу несколько записей
3. удаляем запись из середины (т.е. со значение счетчика меньше последнего)
4. создаем запрос на добавение записи в таблицу с явным указанием значения счетчика равным тому который удалил
5. выполняем запрос
6. открывает таблицу и пытаемся добавить новую запись
7. счетчик будет равен значению добавленному запросом +1 т.е. получим ошибку нарушения ключа....
Ж... какая-то | |
|
| |
|
|
|
| сжать восстановить базу? тогда счетчик пересчитаедза
я вот подумал -а вы строки в ListBox раскрашивали? | |
|
| |
|
|
|
| база многопользовательская,размер окого гига
если я ее после кажодого чиха сжимать буду, работать будет некогда
не на раскрашивал. смотрел у лебанса ... слишком хлопотно | |
|
| |
|
|
|
| понимаю
сталобыть пора переходить на сервер
а зачем так часто менять индекс? пусть себе.... хегачит.... | |
|
| |
|
|
|
| ничего лучшего не придумал.
Нужно редактировать записи , у них есть подчиненные записи в других таблицах которые могут не измениться.
после изменения записи нужно поверить ее на валидность (это порядка 20 проверок по разным параметрам как на правильность содержимого полей записи, так и на уникальность совокупности полей записи в таблице)
Проверка для новых записей сделана.
Что бы не городить все заново для изменяемых пошел таким путем. Удаляю запись и пускаю ее по пути проверки новой записи, при прохождении проверки записываю со старым ключем и новыми значениеми, если нет, то возвращаю старые значения.
Если не записывать со старым ключем по потеряются подчиненные записи или надо что-то придумывать...
Есть еще вариант не удалять, а помечать, но в этом случае придется переписывать процедуру проверки (сейчас участвуювсе записи)
Добавлено.
В принципе пока я это дело пофиксил через рекордсет...
но вероятнее всего пойду по пути отметки и фильтрации, а не удаления. | |
|
| |
|
|
|
| после обработки одной такой ошибки ключа нумерация счетчика восстанавливается? | |
|
| |
|
|
|
|
| может глупость
может бред
Чем не нравится Update?
все проверил и пробил
коль нормально - обновил
| |
|
| |
|
|
|
|
все проверил и пробил - коль нормально - обновил
|
это сам Access должен делать (во всяком случае 2003 делает :) )
в смысле после инсерта в середину (да куда угодно) счетчик продолжается с макс+1 | |
|
| |
|
|
|
| основываясь на этой привычке и делал... ан нет, не тут-то было. | |
|
| |
|
|
|
| я там выше написал... существующая проверка новых записей проверяет новую запись на соответвие разным правилам в этой проверке учавствуют ВСЕ уже существующие записи. Если не удалять то и изменяемая запись попадет под проверку сама с собой. | |
|
| |
|
|
|
|
Проверил у себя, такая - же.
После этого, мне не стыдно продавать свое гамно. | |
|
| |
|
24 Кб. |
|
| => | |
|
| |
|
|
|
| Последний абзац какой-то "детский".
И они называют это трюком? Ужасть! | |
|
| |
|
|
|
| любой баг в программе разработчик может описать как фичу
если только этот баг во благо ;) | |
|
| |
|
|
|
| советчики блин!
они нарушают основной принцип
"счетчик только для уникальности!!!" | |
|
| |
|
7 Кб. |
|
|
вообще книжка оставляет весьма странное впечатление :))) => | |
|
| |
|
|
|
| бочка дёгтя? | |
|
| |
|
|
|
| >>советчики блин!
а антисоветчиков, того, на Колыму или на расстрел | |
|
| |
|
|
|
| osmor
А ты не рассматривал такой вариант
Новая запись на время проверки заполняется какими-то фиксированными значениями
которые при проверке отбрасываются
первый Update
а затем если все подходит
то данные возвращаются на свои места
второй Update
и запись удалять не надо, если она корректная
| |
|
| |
|
|
|
|
А ты не рассматривал такой вариант
|
речь может идти не о разработке новых приложений а об адаптации старых,
в которых метод "замещения записей в дырки" базировался на механизмах Jet.
сейчас механизм хромает, причем, что серьезно, хромает на уровне базовом - на уровне движка СУБД
это очень плохо, думаю пофиксят или уже пофиксили - нужно ждать сервис-паки.
я не думаю, что намеренно изменили алгоритм - не вижу в этом решении логики | |
|
| |
|
|
|
| не думал... наверное это тоже выход. Во всяком случае меньше переписывать чем в случае с установкой отметки и решает проблему с вставкой старого id... Спасибо, идея понятна, надо покрутить в голове | |
|
| |
|
5 Кб. |
|
| Боюсь, такое "жонглирование" данными в памяти не добавит устойчивости.
Вариант с отметкой тоже не FINE, уж если исключать из числа проверяемых записей изменяемую, то
по значению ключевого поля. ИМХО
(OPTION для новых записей в алгоритме проверки или с заведомо проходным дефолтным значением).
Не будет лишнего поля и лишних телодвижений с установкой-снятием отметки.
Добавлено:
Однако, выполнение SELECT-а с фильтром по индексированному логическому полю на 2 млн. записях
примерно в три раза быстрее, чем с фильтром по Long-ключу(счетчику).
Отсекал запись с ID=1999999 (Условно говоря, предпоследнюю по добавлению) => | |
|
| |
|
|
|
|
по значению ключевого поля
|
таки наверное да.
держать ключи "удаленных" записей в отдельной вспомогательной таблице
TableName
RecordID
UserName
DeleteDate | |
|
| |
|
|
|
| Я так понял, одновременно изменяется одна запись, и проверка валидности изменений
должна производиться перед обновлением записи.
В таком случае, достаточно из общего набора записей к проверке исключить одну - измененную(текущую).
Тогда она не будет мешать алгоритму валидации (не будут сравнения измененной текущей записи с ее оригиналом в таблице).
Если валидация прошла успешна - обновление, нет - откат изменений. | |
|
| |
|
|
|
| да -
перечел внимательнее... | |
|
| |
|
|
|
| проверка валидности изменений
должна производиться перед обновлением записи. |
поскольку проверка занимает примерно от 30 сек до 2 мин., то сейчас проверяются все записи измененные /добавленные от открытия формы (или предидущего сохранения) до нажатия кнопки "сохранить". Это может быть и одна запись и много.
Перед началом копирования еще не измененная запись копируется в отдельную таблицу (условно "tblEdetedRecords"), а все изменения сохраняются в главной.
После нажатия кнопки "сохранить". Изменяемые записи с новыми значениями полей копируются в таблицу (условно "tblNewRecords")из которой производится проверка и удаляются из основной (вероятно не будут удаляться). Дальше идет проверка, с выводом после каждого этапа проверки записей "не прошедших" этап с возможностью поправить ошибки (если это возможно). После окончания проверок записи добавляются обратно, либо из таблицы "tblNewRecords" (с новыми значениями) либо из "tblEdetedRecords" (со старыми).
К сожалению пока если изменялись несколько полей, а запись не валидна только по одному, то отменяются все изменения в этой записи. Но дело в том что валидность поля (записи) часто зависит от совокупности полей. и если откатить только часть полей, по запись может стать не валидной. В общем очень сложные проверки. | |
|
| |
|
|
|
| Понятно.
зы. Недавно на соседнем форуме была интересная задачка.
Проверка на валидность осуществлялась по 64 полям с битами.
Автор использовал алгоритм, доказывающий валидность новой записи.
Я попробовал обратный алгоритм, доказывающий не валидность записи.
Оказалось, доказать что запись "плохая" в 50 раз быстрее, чем то, что она "хорошая".
При этом, чем больше уже проверенных записей в таблице, тем быстрее проверялись новые.
В итоге 1000 записей обрабатывалась не 4.5 минуты, а 5.5 секунд. О как. | |
|
| |
|
|
|
|
| да-да-да
This problem may occur when the following conditions are true:
<...>
The table contains an Autonumber field that is not correctly reseeded.
<...>
|
ну фсе - не знаю смеяться или плакать - типа вы сами дураки | |
|
| |