Чудеса: "Исчезающая запись"

[blokva]

DAX 4 SP2, 4.0.2163.0

1. Есть своя табличка наподобе InventSum по поведению.
2. Есть, как полагается, 3 базы (разработка, тест, рабочая)
3. Понадобилось пробежаться по табличке и поменять значения в одном поле.
4. На 1 базе проходит на ура на 2-х других вылетает с ошибкой:
"Невозможно отредактировать запись в Моей табличке (My_Table).
Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи."
5. Эксперимент проводился при 1 пользователе, других процессов нет.
6. Исследуя это явление, открываем нашу табличку в браузере и пробегая по записям просто нажимаем F5 и....
7. Некоторые записи просто обнуляются все числовые поля становятся = 0, а текстовые соответственно пустыми,а большинство нет. Нетрудно догадаться, что обнуляются те записи, котрые порождают эту ошибку. При этом сами записи в таблице не меняются никак.
8. Сравнивание табличек в базах выявило полную их идентичность .

Собственно вопрос: что это может быть и если никто не сталкивался с таким чудом, может есть у кого какие идеи?

зы: наверное это не существенно, но на разработке все ОК, а чудеса творятся на тесте и рабочей!

1. праймари ки не тот
2. синхронизировать попробуй. Не поможет - перенакатить определение таблицы с разработческой

[blokva]

Цитата:

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

1. праймари ки не тот
2. синхронизировать попробуй. Не поможет - перенакатить определение таблицы с разработческой

Пасиб, тока мы все это делали...не помогает...

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

[blokva]

Цитата:

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

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

Спасибо за совет, к сожалению слоем не получится.
Одно не понятно, почему такое вообще возможно...

[glibs]

А каким образом вы бегаете по табличке и обновляете поля?

[aidsua]

Цитата:

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

DAX 4 SP2, 4.0.2163.0
4. На 1 базе проходит на ура на 2-х других вылетает с ошибкой:
"Невозможно отредактировать запись в Моей табличке (My_Table).
Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи."

БД -- MS SQL Server ?

Если ответ положительный -- выполняйте периодически синхронизацию всех таблиц (Администрирование - Периодические операции - Администрирование). Сами напоролись пару раз, когда после сохранения проектов были подобные проблемы.

[blokva]

База SQL 2005...
Провел полную синхронизацию...не помогло
2glibs:
просто открываю браузер таблицы в Аксапте и стрелкой вниз вверх перемещаюсь, при этом нажимаю F5 некоторые записи пропадают, некоторые нет...

[glibs]

Т.е. через форму?

А кэширование на таблице включено какое-нибудь?

[Ed1k]

Цитата:

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

Спасибо за совет, к сожалению слоем не получится.
Одно не понятно, почему такое вообще возможно...

Из-за опции "Экспортировать со значениями идентификаторов"
глюк может быть, если какой-то проект не по общему правилу
перенесли

[fazer]

Цитата:

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

DAX 4 SP2, 4.0.2163.0

1. Есть своя табличка наподобе InventSum по поведению.
2. Есть, как полагается, 3 базы (разработка, тест, рабочая)
3. Понадобилось пробежаться по табличке и поменять значения в одном поле.
4. На 1 базе проходит на ура на 2-х других вылетает с ошибкой:

зы: наверное это не существенно, но на разработке все ОК, а чудеса творятся на тесте и рабочей!

Выложите xpo таблички. Может методы кривые какие..

[blokva]

Одно чудо сменилось на другое:
На выходных забэкапили рабочую базу и отресторили на тестовой "чудо исчезло", причина, так и осталась неразгаданным. Одно ясно, что АОТ ни причем, проблемма была в данных, но вот какая?
Всем спасибо за советы!

[glibs]

Вы дали недостаточно вводной информации. Вам нужно отыскать форум, на котором есть телепаты .

Вот просто еще одна вероятная версия произошедшего. Разрушение одного или нескольких индексов на таблице в рабочей БД. Возможно, у вас отработал maintenance plan, который перестроил индексы.

[blokva]

Цитата:

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

Вы дали недостаточно вводной информации. Вам нужно отыскать форум, на котором есть телепаты .

Вот просто еще одна вероятная версия произошедшего. Разрушение одного или нескольких индексов на таблице в рабочей БД. Возможно, у вас отработал maintenance plan, который перестроил индексы.

Согласен с намеком на телепатов, соответствующим образом обозвана тема.
По поводу индексов, я уже писал, что перестраивал по всей базе и по злополучной таблице и даже удалял индексы у нее с последующим построением - не помогло. На счет maintenance plan может быть и это...

[glibs]

Цитата:

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

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

Просмотрел еще раз все ваши сообщения... не нашел. Только про синхронизацию. Глючит меня, наверное...

Если вы под перестроенем индексов понимаете синхронизацию, то это разные вещи.

[blokva]

Цитата:

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

Просмотрел еще раз все ваши сообщения... не нашел. Только про синхронизацию. Глючит меня, наверное...

Если вы под перестроенем индексов понимаете синхронизацию, то это разные вещи.

Виноват, действительно не написал, хотя все это действительно проделал...

[dirigente]

Такое происходит при смене выравнивания в любом поле таблицы c left на right. Эффект стабильный: на любой таблице после изменения выравнивания по нажатии F5 запись "пропадает". Также невозможно внести в строку каки-либо изменения (в любом поле) - вылетает ошибка.
Причина: данные в SQL остаются с выравниванием left, а в AOT - right. Танцы с бубном, "попинать" не помогают. Хочется найти способ проще, чем написание скрипта в базе.
Может, кто-нибудь придумал как с этим бороться?

[DSPIC]

Цитата:

Такое происходит при смене выравнивания в любом поле таблицы c left на right. Эффект стабильный: на любой таблице после изменения выравнивания по нажатии F5 запись "пропадает"

Только что поигрался - при таких движениях у меня проблем не возникает (DAX4sp2, SQL2k5)
Но аналогичная проблема (сабж) возникала при DataUpgrade 3.0->4.0. Выяснилось, что при апгрейде некорректно обработали данные, у которых Adjustment=Right. Посмотрев на таблицу в SQLе увидел, что в значения полей первичного ключа спереди влезли пробелы. Сделал просто - в 4ке поставил Adjustment = Left, и всё стало работать корректно.

Цитата:

Причина: данные в SQL остаются с выравниванием left, а в AOT - right.

P.S. После смены выравнивания Right->Left пробелы в SQL таблице "ушли"

[mazzy]

Цитата:

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

Такое происходит при смене выравнивания в любом поле таблицы c left на right. Эффект стабильный: на любой таблице после изменения выравнивания по нажатии F5 запись "пропадает". Также невозможно внести в строку каки-либо изменения (в любом поле) - вылетает ошибка.
Причина: данные в SQL остаются с выравниванием left, а в AOT - right. Танцы с бубном, "попинать" не помогают. Хочется найти способ проще, чем написание скрипта в базе.
Может, кто-нибудь придумал как с этим бороться?

после смены выравнивания клиентов стоит перегрузит.
сколко раз делал подобную операцию - проблем не было.

[dirigente]

Цитата:

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

... Посмотрев на таблицу в SQLе увидел, что в значения полей первичного ключа спереди влезли пробелы. Сделал просто - в 4ке поставил Adjustment = Left, и всё стало работать корректно.

Эти "пробелы" и есть смысл Adjustment = Right и нам необходимо его сохранить.

Цитата:

после смены выравнивания клиентов стоит перегрузит.
сколко раз делал подобную операцию - проблем не было.

2 mazzy: клиентов перегружали - не помогает.

Проблем может не возникать только если при смене выравнивания с Left на Right в базе происходит преобразование значений добавлением ведущих пробелов (перед значением). У вас так?
У нас такого не происходит, т.е. значения остаются "выровненными" влево. Отсюда и ошибка лезет.
В обратную сторону (т.е. при смене right -> left) - все в порядке.
DynAx40SP2, SQL 2005