|
|
29.08.2007, 16:43
|
#1 |
|
Пенсионер
|
Чудеса: "Исчезающая запись"
DAX 4 SP2, 4.0.2163.0
1. Есть своя табличка наподобе InventSum по поведению. 2. Есть, как полагается, 3 базы (разработка, тест, рабочая) 3. Понадобилось пробежаться по табличке и поменять значения в одном поле. 4. На 1 базе проходит на ура на 2-х других вылетает с ошибкой: "Невозможно отредактировать запись в Моей табличке (My_Table). Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи." 5. Эксперимент проводился при 1 пользователе, других процессов нет. 6. Исследуя это явление, открываем нашу табличку в браузере и пробегая по записям просто нажимаем F5 и.... 7. Некоторые записи просто обнуляются все числовые поля становятся = 0, а текстовые соответственно пустыми,а большинство нет. Нетрудно догадаться, что обнуляются те записи, котрые порождают эту ошибку. При этом сами записи в таблице не меняются никак. 8. Сравнивание табличек в базах выявило полную их идентичность . Собственно вопрос: что это может быть и если никто не сталкивался с таким чудом, может есть у кого какие идеи? зы: наверное это не существенно, но на разработке все ОК, а чудеса творятся на тесте и рабочей!
__________________
 Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ Последний раз редактировалось blokva; 29.08.2007 в 17:05. |
|
|
|
29.08.2007, 17:35
|
#2 |
|
Гость
|
1. праймари ки не тот
2. синхронизировать попробуй. Не поможет - перенакатить определение таблицы с разработческой |
|
|
|
30.08.2007, 11:40
|
#3 |
|
Пенсионер
|
Цитата:
Сообщение от otkudao
1. праймари ки не тот
2. синхронизировать попробуй. Не поможет - перенакатить определение таблицы с разработческой
__________________
Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
30.08.2007, 12:35
|
#4 |
|
Гость
|
значит, при накате проекта изменений записывается неправильно.
Если разработческое приложение == тестовому, перенесите его слоем. |
|
|
|
31.08.2007, 07:26
|
#5 |
|
Пенсионер
|
Цитата:
Сообщение от otkudao
значит, при накате проекта изменений записывается неправильно.
Если разработческое приложение == тестовому, перенесите его слоем. Одно не понятно, почему такое вообще возможно...
__________________
Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
31.08.2007, 17:54
|
#6 |
|
Участник
|
Цитата:
Сообщение от blokva
Спасибо за совет, к сожалению слоем не получится.
Одно не понятно, почему такое вообще возможно... глюк может быть, если какой-то проект не по общему правилу перенесли |
|
|
|
31.08.2007, 09:29
|
#7 |
|
Member
|
А каким образом вы бегаете по табличке и обновляете поля?
__________________
С уважением, glibs® |
|
|
|
31.08.2007, 15:04
|
#8 |
|
AX*****
|
Цитата:
Сообщение от blokva
DAX 4 SP2, 4.0.2163.0
4. На 1 базе проходит на ура на 2-х других вылетает с ошибкой: "Невозможно отредактировать запись в Моей табличке (My_Table). Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи." Если ответ положительный -- выполняйте периодически синхронизацию всех таблиц (Администрирование - Периодические операции - Администрирование). Сами напоролись пару раз, когда после сохранения проектов были подобные проблемы.
__________________
О, как беден, как груб наш русский язык! [c] А.С.Пушкин |
|
|
|
31.08.2007, 17:14
|
#9 |
|
Пенсионер
|
База SQL 2005...
Провел полную синхронизацию...не помогло  2glibs: просто открываю браузер таблицы в Аксапте и стрелкой вниз вверх перемещаюсь, при этом нажимаю F5 некоторые записи пропадают, некоторые нет...
__________________
Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
31.08.2007, 17:34
|
#10 |
|
Member
|
Т.е. через форму?
А кэширование на таблице включено какое-нибудь?
__________________
С уважением, glibs® |
|
|
|
31.08.2007, 18:30
|
#11 |
|
Участник
|
Цитата:
Сообщение от blokva
DAX 4 SP2, 4.0.2163.0
1. Есть своя табличка наподобе InventSum по поведению. 2. Есть, как полагается, 3 базы (разработка, тест, рабочая) 3. Понадобилось пробежаться по табличке и поменять значения в одном поле. 4. На 1 базе проходит на ура на 2-х других вылетает с ошибкой: зы: наверное это не существенно, но на разработке все ОК, а чудеса творятся на тесте и рабочей! 
|
|
|
|
03.09.2007, 08:09
|
#12 |
|
Пенсионер
|
Одно чудо сменилось на другое:
На выходных забэкапили рабочую базу и отресторили на тестовой "чудо исчезло", причина, так и осталась неразгаданным. Одно ясно, что АОТ ни причем, проблемма была в данных, но вот какая? Всем спасибо за советы!
__________________
Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
03.09.2007, 10:08
|
#13 |
|
Member
|
Вы дали недостаточно вводной информации. Вам нужно отыскать форум, на котором есть телепаты
 .Вот просто еще одна вероятная версия произошедшего. Разрушение одного или нескольких индексов на таблице в рабочей БД. Возможно, у вас отработал maintenance plan, который перестроил индексы.
__________________
С уважением, glibs® |
|
|
|
03.09.2007, 11:17
|
#14 |
|
Пенсионер
|
Цитата:
Сообщение от glibs
Вы дали недостаточно вводной информации. Вам нужно отыскать форум, на котором есть телепаты
.Вот просто еще одна вероятная версия произошедшего. Разрушение одного или нескольких индексов на таблице в рабочей БД. Возможно, у вас отработал maintenance plan, который перестроил индексы. По поводу индексов, я уже писал, что перестраивал по всей базе и по злополучной таблице и даже удалял индексы у нее с последующим построением - не помогло. На счет maintenance plan может быть и это...
__________________
Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
03.09.2007, 11:37
|
#15 |
|
Member
|
Цитата:
Сообщение от blokva
...
я уже писал, что перестраивал по всей базе и по злополучной таблице и даже удалял индексы у нее с последующим построением - не помогло. ... Если вы под перестроенем индексов понимаете синхронизацию, то это разные вещи.
__________________
С уважением, glibs® |
|
|
|
03.09.2007, 13:12
|
#16 |
|
Пенсионер
|
Цитата:
Сообщение от glibs
Просмотрел еще раз все ваши сообщения... не нашел. Только про синхронизацию. Глючит меня, наверное...
Если вы под перестроенем индексов понимаете синхронизацию, то это разные вещи.
__________________
Законы природы еще никто не отменял!А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
|
|
11.08.2008, 14:51
|
#17 |
|
Участник
|
Возможная разгадка чуда
Такое происходит при смене выравнивания в любом поле таблицы c left на right. Эффект стабильный: на любой таблице после изменения выравнивания по нажатии F5 запись "пропадает". Также невозможно внести в строку каки-либо изменения (в любом поле) - вылетает ошибка.
Причина: данные в SQL остаются с выравниванием left, а в AOT - right. Танцы с бубном, "попинать" не помогают. Хочется найти способ проще, чем написание скрипта в базе. Может, кто-нибудь придумал как с этим бороться?
__________________
С уважением, Dirigente |
|
|
|
11.08.2008, 15:25
|
#18 |
|
Боец
|
Цитата:
Такое происходит при смене выравнивания в любом поле таблицы c left на right. Эффект стабильный: на любой таблице после изменения выравнивания по нажатии F5 запись "пропадает"
Но аналогичная проблема (сабж) возникала при DataUpgrade 3.0->4.0. Выяснилось, что при апгрейде некорректно обработали данные, у которых Adjustment=Right. Посмотрев на таблицу в SQLе увидел, что в значения полей первичного ключа спереди влезли пробелы. Сделал просто - в 4ке поставил Adjustment = Left, и всё стало работать корректно. Цитата:
Причина: данные в SQL остаются с выравниванием left, а в AOT - right.
Последний раз редактировалось DSPIC; 11.08.2008 в 15:29. Причина: Уточнение |
|
|
|
11.08.2008, 16:18
|
#19 |
|
Участник
|
Цитата:
Сообщение от DSPIC
... Посмотрев на таблицу в SQLе увидел, что в значения полей первичного ключа спереди влезли пробелы. Сделал просто - в 4ке поставил Adjustment = Left, и всё стало работать корректно.
Цитата:
после смены выравнивания клиентов стоит перегрузит.
сколко раз делал подобную операцию - проблем не было. Проблем может не возникать только если при смене выравнивания с Left на Right в базе происходит преобразование значений добавлением ведущих пробелов (перед значением). У вас так? У нас такого не происходит, т.е. значения остаются "выровненными" влево. Отсюда и ошибка лезет. В обратную сторону (т.е. при смене right -> left) - все в порядке. DynAx40SP2, SQL 2005
__________________
С уважением, Dirigente |
|
|
|
11.08.2008, 16:37
|
#20 |
|
Участник
|
Цитата:
Сообщение от dirigente
Проблем может не возникать только если при смене выравнивания с Left на Right в базе происходит преобразование значений добавлением ведущих пробелов (перед значением). У вас так?
синхронизация может выполнятся долго и может заблокировать пользователей. перед синхронозацией рекомендуется почистить базу http://axapta.mazzy.ru/lib/dbgrowthsolution/ и сразу значительно увеличито transaction log Цитата:
Сообщение от dirigente
У нас такого не происходит, т.е. значения остаются "выровненными" влево. Отсюда и ошибка лезет.
В обратную сторону (т.е. при смене right -> left) - все в порядке. DynAx40SP2, SQL 2005
|
|
|
Комбинированный вид
