![]() |
#1 |
Участник
|
UNKNOWN table
AX4
PHP код:
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#2 |
Administrator
|
Лечение "топором" можно попробовать. Сам не сталкивался - но гуру рассказывали. Если есть возможность найти эту табличку в Util*-такбличках и удалить оттуда все записи в отношении этой таблички - то вылечится. Это при условии, что у вас в АОТ проблемы (как я понял проблемы ведь при компиляции).
Но если честно - то сам не сталкивался
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#3 |
Модератор
|
Как собственно таблица называется?
вы уверены что таблица написана так как она и называется? Может одна буква в названии таблицы или пропущена или русская(а выглядит как агнл. ![]() Таблица используется в каком то методе? Код можно? |
|
![]() |
#4 |
Участник
|
Цитата:
МорфХ таблицу видит, никаких ошибок не выдает при редактировании кода, вылетает при попытке использования такого кода.
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#5 |
Участник
|
Цитата:
PHP код:
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#6 |
Administrator
|
Цитата:
Тогда почти уверен, что у вас "схлестнулись" ID-шники. Т.е. в приложении у вас 2 элемента (2 таблицы/ Map/ View) с одинаковыми Id. Увидеть вы это вряд ли сможете (чтобы найти такие элементы - нужно джобиком "прогуляться" по АОТу сразу после подкладывания слоя, перестроения индексов и до выхода из Аксапты). Решение: Выяснить (у вас же есть копия приложения) - что за ID-шник у этой таблицы / Map/ View был и есть ли такой ID-шник у таблицы /Map/View в приложении, в которое вы подкладываете слой. "Исправить" Id (табличку выгрузить и загрузить заново без сохранения ID) на копии, после чего подкладывать слой. Вообще, хочу отметить - что подкладывание слоев - вещь классная, но надо четко следить за Id-шниками элементов. Кстати - нет никакой гарантии, что это единственная грабля. Для полной уверенности - перед подкладыванием слоя - нужно убедиться - что во всех слоях сидят элементы только "со своими" Id-шниками.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: DTD (1). |
![]() |
#7 |
Модератор
|
DTD
Попробуй поправить id Администрирование\Администрирование SQL\Действами над таблицами\ [Проверка/Синхронизация] если Ax4 SP2 то кнопка [Проверка/Синхронизация] заблокирована. Можешь поправить Forms\sysSqlAdmin\ кнопка buttonCheckTable Enable=Yes |
|
![]() |
#8 |
Участник
|
Пробовал первым делом, не помогло
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#9 |
Member
|
Вы не пробовали что-то поменять в свойствах таблицы и самом методе, сохранив их?
Ну и для начала проделать это с тем методом, который обращается к таблице.
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: DTD (1). |
![]() |
#10 |
Участник
|
Цитата:
Сообщение от sukhanchik
![]() Дык это... слой - файликом перекидывали?
Тогда почти уверен, что у вас "схлестнулись" ID-шники. Т.е. в приложении у вас 2 элемента (2 таблицы/ Map/ View) с одинаковыми Id. Увидеть вы это вряд ли сможете (чтобы найти такие элементы - нужно джобиком "прогуляться" по АОТу сразу после подкладывания слоя, перестроения индексов и до выхода из Аксапты). Цитата:
Сообщение от sukhanchik
![]() Решение: Выяснить (у вас же есть копия приложения) - что за ID-шник у этой таблицы / Map/ View был и есть ли такой ID-шник у таблицы /Map/View в приложении, в которое вы подкладываете слой. "Исправить" Id (табличку выгрузить и загрузить заново без сохранения ID) на копии, после чего подкладывать слой.
Цитата:
Сообщение от sukhanchik
![]() Вообще, хочу отметить - что подкладывание слоев - вещь классная, но надо четко следить за Id-шниками элементов.
Кстати - нет никакой гарантии, что это единственная грабля. Для полной уверенности - перед подкладыванием слоя - нужно убедиться - что во всех слоях сидят элементы только "со своими" Id-шниками.
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#11 |
Участник
|
Цитата:
спасибо всем !
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#12 |
Member
|
Вероятно, перенеся скомпилированный слой, у вас код скомпилировался с одним ID таблицы, а после переноса он умудрился измениться. По тому ID, который был в скомпилированном коде, таблица не находилась. Вот и получался UNKNOWN.
Толи на форуме писали почему, толи мне приснилось... но компиляция делает свою работу не всегда, почему-то. Иногда если исходный код нетронут, то она ленится компилировать. Либо что-то происходит, что приводит к такому эффекту. Модификация, обычно, лечит такие косяки.
__________________
С уважением, glibs® |
|
![]() |
#13 |
Боец
|
Яркий пример тому - макросы. Если в ClassDeclaration положить макрос из AOT, а затем в том макросе поменять какой-либо параметр, то несмотря на перекомпиляцию класса новое значение не подтягивается, пока не промодифицируешь ClassDeclaration, хотябы пробелом.
|
|
![]() |
#14 |
Участник
|
Кстати раз уже эту тему затронули, никогда не задумывался почeму её убрали, просто включал назад на форме и все. Кто нибудь знает какие предпосылки для этого решения были ?
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#15 |
Участник
|
Она может нарушить целостность данных системы.
![]() Поэтому, не очень хороший совет бездумно ее включать. В дальнейшем ее починили (АХ 2009) |
|
![]() |
#16 |
Участник
|
я об этом слышал, а где конкретно почитать в каких ситуациях она может нарушить целостность данных системы ?
__________________
_databaseTransDelete ... bl@$ ! |
|
![]() |
#17 |
Member
|
__________________
С уважением, glibs® |
|
Теги |
баг, ax4.0 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|