Rambler's Top100
Форум: MS ACCESSVBVBA MS OfficeMS SQL server
Новые сообщения: 0000

Форум: MS ACCESS

Вопросы связанные с MS ACCESS

Обновить визитку
Участники «Online»
Все участники

 
 

Доброго времени суток, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: багофича сот счетчиком msa 2007
 
 автор: osmor   (24.02.2010 в 11:05)   личное сообщение
 
 

столкнутся вчера... потратил 2 часа на поиски решения... может у меня не все фиксы стоят какие надо?

последовательность действий для получения эффекта.
1. создаем таблицу в которой id будет счетчик (остальные поля не важны)
2. добавляем руками в таблицу несколько записей
3. удаляем запись из середины (т.е. со значение счетчика меньше последнего)
4. создаем запрос на добавение записи в таблицу с явным указанием значения счетчика равным тому который удалил
5. выполняем запрос
6. открывает таблицу и пытаемся добавить новую запись
7. счетчик будет равен значению добавленному запросом +1 т.е. получим ошибку нарушения ключа....
Ж... какая-то

  Ответить  
 
 автор: Силblч   (24.02.2010 в 11:08)   личное сообщение
 
 

сжать восстановить базу? тогда счетчик пересчитаедза

я вот подумал -а вы строки в ListBox раскрашивали?

  Ответить  
 
 автор: osmor   (24.02.2010 в 11:32)   личное сообщение
 
 

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

не на раскрашивал. смотрел у лебанса ... слишком хлопотно

  Ответить  
 
 автор: Силblч   (24.02.2010 в 11:43)   личное сообщение
 
 

понимаю
сталобыть пора переходить на сервер

а зачем так часто менять индекс? пусть себе.... хегачит....

  Ответить  
 
 автор: osmor   (24.02.2010 в 12:03)   личное сообщение
 
 

ничего лучшего не придумал.

Нужно редактировать записи , у них есть подчиненные записи в других таблицах которые могут не измениться.
после изменения записи нужно поверить ее на валидность (это порядка 20 проверок по разным параметрам как на правильность содержимого полей записи, так и на уникальность совокупности полей записи в таблице)
Проверка для новых записей сделана.
Что бы не городить все заново для изменяемых пошел таким путем. Удаляю запись и пускаю ее по пути проверки новой записи, при прохождении проверки записываю со старым ключем и новыми значениеми, если нет, то возвращаю старые значения.
Если не записывать со старым ключем по потеряются подчиненные записи или надо что-то придумывать...
Есть еще вариант не удалять, а помечать, но в этом случае придется переписывать процедуру проверки (сейчас участвуювсе записи)

Добавлено.
В принципе пока я это дело пофиксил через рекордсет...
но вероятнее всего пойду по пути отметки и фильтрации, а не удаления.

  Ответить  
 
 автор: Explorer   (24.02.2010 в 11:35)   личное сообщение
 
 

после обработки одной такой ошибки ключа нумерация счетчика восстанавливается?

  Ответить  
 
 автор: osmor   (24.02.2010 в 11:57)   личное сообщение
 
 

нет

  Ответить  
 
 автор: ShadowOfSun   (24.02.2010 в 12:32)   личное сообщение
 
 

может глупость
может бред
Чем не нравится Update?
все проверил и пробил
коль нормально - обновил

  Ответить  
 
 автор: Explorer   (24.02.2010 в 13:04)   личное сообщение
 
 


все проверил и пробил - коль нормально - обновил



это сам Access должен делать (во всяком случае 2003 делает :) )

в смысле после инсерта в середину (да куда угодно) счетчик продолжается с макс+1

  Ответить  
 
 автор: osmor   (24.02.2010 в 14:57)   личное сообщение
 
 

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

  Ответить  
 
 автор: osmor   (24.02.2010 в 14:59)   личное сообщение
 
 

я там выше написал... существующая проверка новых записей проверяет новую запись на соответвие разным правилам в этой проверке учавствуют ВСЕ уже существующие записи. Если не удалять то и изменяемая запись попадет под проверку сама с собой.

  Ответить  
 
 автор: Lukas   (24.02.2010 в 13:17)   личное сообщение
 
 


Ж... какая-то


Проверил у себя, такая - же.

После этого, мне не стыдно продавать свое гамно.

  Ответить  
 
 автор: Explorer   (24.02.2010 в 13:44)   личное сообщение
24 Кб.
 
 

=>

  Ответить  
 
 автор: Lukas   (24.02.2010 в 13:58)   личное сообщение
 
 

Последний абзац какой-то "детский".
И они называют это трюком? Ужасть!

  Ответить  
 
 автор: Силblч   (24.02.2010 в 14:27)   личное сообщение
 
 

любой баг в программе разработчик может описать как фичу
если только этот баг во благо ;)

  Ответить  
 
 автор: osmor   (24.02.2010 в 14:55)   личное сообщение
 
 

советчики блин!
они нарушают основной принцип
"счетчик только для уникальности!!!"

  Ответить  
 
 автор: Explorer   (24.02.2010 в 14:59)   личное сообщение
7 Кб.
 
 


советчики блин!



вообще книжка оставляет весьма странное впечатление :))) =>

  Ответить  
 
 автор: Силblч   (24.02.2010 в 15:07)   личное сообщение
 
 

бочка дёгтя?

  Ответить  
 
 автор: Силblч   (24.02.2010 в 15:07)   личное сообщение
 
 

>>советчики блин!
а антисоветчиков, того, на Колыму или на расстрел

  Ответить  
 
 автор: ShadowOfSun   (24.02.2010 в 15:33)   личное сообщение
 
 

osmor
А ты не рассматривал такой вариант
Новая запись на время проверки заполняется какими-то фиксированными значениями
которые при проверке отбрасываются
первый Update

а затем если все подходит
то данные возвращаются на свои места
второй Update
и запись удалять не надо, если она корректная

  Ответить  
 
 автор: Explorer   (24.02.2010 в 16:11)   личное сообщение
 
 


А ты не рассматривал такой вариант


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

сейчас механизм хромает, причем, что серьезно, хромает на уровне базовом - на уровне движка СУБД

это очень плохо, думаю пофиксят или уже пофиксили - нужно ждать сервис-паки.
я не думаю, что намеренно изменили алгоритм - не вижу в этом решении логики

  Ответить  
 
 автор: osmor   (24.02.2010 в 18:01)   личное сообщение
 
 

не думал... наверное это тоже выход. Во всяком случае меньше переписывать чем в случае с установкой отметки и решает проблему с вставкой старого id... Спасибо, идея понятна, надо покрутить в голове

  Ответить  
 
 автор: Lukas   (24.02.2010 в 19:42)   личное сообщение
5 Кб.
 
 

Боюсь, такое "жонглирование" данными в памяти не добавит устойчивости.
Вариант с отметкой тоже не FINE, уж если исключать из числа проверяемых записей изменяемую, то
по значению ключевого поля. ИМХО
(OPTION для новых записей в алгоритме проверки или с заведомо проходным дефолтным значением).
Не будет лишнего поля и лишних телодвижений с установкой-снятием отметки.


Добавлено:
Однако, выполнение SELECT-а с фильтром по индексированному логическому полю на 2 млн. записях
примерно в три раза быстрее, чем с фильтром по Long-ключу(счетчику).
Отсекал запись с ID=1999999 (Условно говоря, предпоследнюю по добавлению) =>

  Ответить  
 
 автор: Explorer   (24.02.2010 в 19:48)   личное сообщение
 
 


по значению ключевого поля



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

TableName
RecordID
UserName
DeleteDate

  Ответить  
 
 автор: Lukas   (24.02.2010 в 20:07)   личное сообщение
 
 

Я так понял, одновременно изменяется одна запись, и проверка валидности изменений
должна производиться перед обновлением записи.
В таком случае, достаточно из общего набора записей к проверке исключить одну - измененную(текущую).
Тогда она не будет мешать алгоритму валидации (не будут сравнения измененной текущей записи с ее оригиналом в таблице).
Если валидация прошла успешна - обновление, нет - откат изменений.

  Ответить  
 
 автор: Explorer   (24.02.2010 в 20:13)   личное сообщение
 
 

да -

перечел внимательнее...

  Ответить  
 
 автор: osmor   (25.02.2010 в 08:08)   личное сообщение
 
 

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


поскольку проверка занимает примерно от 30 сек до 2 мин., то сейчас проверяются все записи измененные /добавленные от открытия формы (или предидущего сохранения) до нажатия кнопки "сохранить". Это может быть и одна запись и много.
Перед началом копирования еще не измененная запись копируется в отдельную таблицу (условно "tblEdetedRecords"), а все изменения сохраняются в главной.
После нажатия кнопки "сохранить". Изменяемые записи с новыми значениями полей копируются в таблицу (условно "tblNewRecords")из которой производится проверка и удаляются из основной (вероятно не будут удаляться). Дальше идет проверка, с выводом после каждого этапа проверки записей "не прошедших" этап с возможностью поправить ошибки (если это возможно). После окончания проверок записи добавляются обратно, либо из таблицы "tblNewRecords" (с новыми значениями) либо из "tblEdetedRecords" (со старыми).
К сожалению пока если изменялись несколько полей, а запись не валидна только по одному, то отменяются все изменения в этой записи. Но дело в том что валидность поля (записи) часто зависит от совокупности полей. и если откатить только часть полей, по запись может стать не валидной. В общем очень сложные проверки.

  Ответить  
 
 автор: Lukas   (25.02.2010 в 13:12)   личное сообщение
 
 

Понятно.

зы. Недавно на соседнем форуме была интересная задачка.
Проверка на валидность осуществлялась по 64 полям с битами.
Автор использовал алгоритм, доказывающий валидность новой записи.
Я попробовал обратный алгоритм, доказывающий не валидность записи.
Оказалось, доказать что запись "плохая" в 50 раз быстрее, чем то, что она "хорошая".
При этом, чем больше уже проверенных записей в таблице, тем быстрее проверялись новые.
В итоге 1000 записей обрабатывалась не 4.5 минуты, а 5.5 секунд. О как.

  Ответить  
 
 автор: Serge Gavrilov   (25.02.2010 в 15:42)   личное сообщение
 
 

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

  Ответить  
 
 автор: Explorer   (25.02.2010 в 16:31)   личное сообщение
 
 

да-да-да


This problem may occur when the following conditions are true:
<...>
The table contains an Autonumber field that is not correctly reseeded.
<...>



ну фсе - не знаю смеяться или плакать - типа вы сами дураки

  Ответить  
HiProg.com - Технологии программирования
Rambler's Top100 TopList