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