| 
			
			 | 
		#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®  | 
| 
	
 |