Их надо знать в лицо

[miklenew]

Цитата:

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

кроме того, могут быть следующие случаи:
1. таблицы могут быть обернуты map'ом, а уже map активно используется
2. таблицы обернуты классом, который используется. А сама таблица напрямую используется редко

Вобще то конечно правильно. Насчет класов мысли были, но сначало список таблиц доделать хочется. Отобрать первичные и второстепенные. Возможно составить схему. По крайней мере попробую. Не уверен ещё в собственных силах. Но если двигаться в нужном направлении должно получиться. Когда с классами будет хоть какой-то адекватный результат. Можно анализировать информацию 1 и 2. Таблицы+классы. Пока наверное ограничусь без информации от Map-ов и классов. Хотя Map-ы тоже навеное посчитать можно. Подумаю.

[miklenew]

Да если кому-то интересно какая таблица какому модулю принадлежит, вот полный список. Вернее не совсем полный. !dictTable.isTmp() && dictTable.isSql().

[mazzy]

Цитата:

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

какая таблица какому модулю принадлежит

Я еще раз настаиваю на том, что ваша логика ошибочна.

1. Сама таблица логически не может принадлежать модулю.
2. модулю "принадлежат" данные (вернее, совокупность логически связанных данных образует модуль)
3. данные хранятся в полях
4. т.е. анализировать надо принадлежность полей к тому или иному модулю
5. это значит, что таблица может принадлежать нескольким модулям одновременно
6. параметр ConfigurationKey, указанный в самой таблице дает слишком общую информацию. Этот параметр определяет при покупке какого модуля эта таблица появится. Но он не определяет к какому модулю таблица принадлежит (вот такой вот логический выверт). Например, банк появляется при покупке лицензии Finance I и т.п.

См. http://axapta.mazzy.ru/lib/explore/
Этот мир - иллюзия. Вы начали изучайть эту матрицу при помощи внутренних кодов. Не останавливайтесь на полпути.

[miklenew]

Цитата:

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

4. т.е. анализировать надо принадлежность полей к тому или иному модулю

Я так понимаю, если мы отключаем ключ. А на таблице привязан этот ключ, то таблицой мы уже не сможем воспользоваться. Если не ошибаюсь они ещё и обнуляются при отключение ключа. Соответственно для тех таблиц у которых есть привязки нам это не важно. А вот у тех, у кого нет привязок к ключам наверное важно.

[mazzy]

Цитата:

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

Если не ошибаюсь они ещё и обнуляются при отключение ключа.

Эти поля физически уничтожаются при помощи Alter Table.
А таблицы физически уничтожаются при помощи Drop Table при выключении ключа.
Соответственно данные "обнуляются"

Цитата:

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

Соответственно для тех таблиц у которых есть привязки нам это не важно.

Важно, важно.

[miklenew]

Цитата:

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

4. т.е. анализировать надо принадлежность полей к тому или иному модулю

Сделал три таблицы.
1)TableProperty
поля:
TableName - имя таблицы
LabelTable - русское
ConfigurationkeyName - имя ключа таблицы
LabelConfigurationkey - русское
CountRecId - количество записей
CountReference - количество ссылок таблиц
2) TableInMaps
поля
TableName - имя таблицы
LabelTable - русское
MapsName - имя мапа
CountReference - количество ссылок мапа
3)FieldsInTable
поля
TableName - имя таблицы
LabelTable - русское
ConfigurationkeyName - имя ключа поля
LabelConfigurationkey - русское
FieldNum - номер поля
FieldName -имя поля
FieldLabel - русское
CountReference - количество ссылок поля

Заполнил их. Из этой информации уже можно определить. Каким ещё модулям принадлежит таблица, если исходить не из ключа таблицы, а из ключей полей таблицы. Можно проссумировать ссылки таблиц и их мапов, для более адэкватного анализа. Будет ли это правильно? А то у меня сомнения ещё остаются.

[miklenew]

Получился вот такой список. С учётом ключей полей и ссылки таблиц + ссылки мапов в которые входят эти таблицы. Но считаю всё же основные таблицы надо определять из первого списка. А второй иметь ввиду при состовлении связей. Потому что как раз в новых строчках модули и соединяются. Хотя не только в них.