|  10.04.2002, 11:28 | #1 | 
| Moderator | Синхронизация таблиц 
			
			Иногда бывает следующая ситуация: разрабатывалась функциональность на одной копии Аксапты и одной базе данных. На другой комии Аксапты и другой базе данных (ДРУГАЯ БАЗА ДАННЫХ - мне кажется здесь ключевым моментом), импортируем проект и запускается синхронизации. В ходе синхронизации появляются ошибки примерно такого вида: [Microsoft][ODBC SQL Server Driver][SQL Server]There is already an object named 'DEM_REQ_VERSION' in the database. DEM_REQ_VERSION - это таблица. Как я понимаю при синхронизации Аксапта пытается создать таблицу, но так как она там уже есть она не может сделать это. В дальнейшем при работе в Аксапте с этими таблицами появляются следующие ошибки: [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid column name 'VERSION'. То есть, как я понимаю, таблица на SQL Servere отличается от представления ожидаемого Аксаптой. Но синхронизировать ее я не могу. Не сталкивались ли Вы в этом ? Как с этим бороться ? | 
|  | 
|  10.04.2002, 11:32 | #2 | 
| Moderator | 
			
			Да еще, если предварительно экспортировать данные из таблиц, залезть в SQL Server, удалить эти таблицы, войти в Аксатпу, синхронизировать проект и закачать обратно данные - то все будет нормально. Но ведь это же не выход ??? | 
|  | 
|  10.04.2002, 12:32 | #3 | 
| ---------------- | 
			
			Такая проблема возникала, когда на SQL-сервере уже существовала таблица созданная неким пользователем (например somebody), а Аксапта при синхронизации пытается создать такую же таблицу, но с другим пользователем (например dbo)... с тем самым, который указан в настройках Вашего ODBC.
		 | 
|  | 
|  10.04.2002, 13:37 | #4 | 
| сибиряк | 
			
			Проблема точно в различии имени владельца объекта существующего на SQL-server и того, который импортируется.  Вообще, owner'ом всех объектов на SQL-сервере должен быть dbo. Уж не помню где, но читал об этом. Остальным пользователям должны бать только grant'ованы различные права на объекты. Нормальная практика - после импорта разработок запускать на сервере stored procedure, которая бы приводила владельцев всех объектов к единому (лучше dbo  ). А после этого синхронизировать базу средствами Аксапты. 
				__________________ С уважением, Вячеслав. | 
|  | 
|  10.04.2002, 14:05 | #5 | 
| Участник | 
			
			Прошу прощения за вмешательство, но... Причина достаточно банальна. У каждой таблицы есть id, хранимый в приложении (а не БД, что очень важно!), при чем этот id зависит от слоя, где объявлена таблица и от порядка импорта проектов. Когда идет импорт проекта, экспортированного из одного приложения, в другое приложение, id таблиц в одном приложении и другом будут разные (правда, могут и совпасть). Аксапта при синхронизации проверяет не только название таблиц, но и их id в базе и приложении. У нас такое постоянно происходит при перемещении проекта с одного слоя на другой. Гарантированный выход я знаю только один: экспорт всех таких таблиц перед синхронизацией и импорт после синхронизации. Другой способ: копирование приложения не экспортом-импортом проектов, а копированием самих файлов с приложением. Но это при работающей базе нереально. | 
|  | 
|  11.04.2002, 20:38 | #6 | 
| Участник | 
			
			Присоединяюсь к диагнозу Михаилу Андрееву. Однако Михаил предлагает слишком жесткое решение. Рекомендую Best Practice. Раздел Cost Efficient Upgrades http://technet.navision.com/usered/B...t_Upgrades.htm | 
|  | 
|  12.04.2002, 10:29 | #7 | 
| ---------------- | 
			
			Из личного опыта - При импорте-экспорте проекта в XPO файле нет информации о TableId   | 
|  |