Внешний источник данных - файл EXCEL
 

есть файл экселя. в нем технические параметры комплектующих. Причем у разных единиц набор параметров может отличаться по количеству параметров (у кого-то только один диаметр присоединительной резьбы, у другого - два диаметра, у третьего четыре, у пятого есть еще и угол изгиба и т.п.).
Т.е. заранее сколько будет полей (и листов) в файле неизвестно. Но хотелось бы использовать эти данные в запросе через внешний источник данных. Вот только непонятно, как обработчик будет работать с такой структурой... Кто-нибудь делал что-нибудь похожее?

ну в 1С 7.7 делали )))

0-bma1 > А эти самые ексели, что, делаются разными людьми, со своим собственными [em]хохряками[/em]? Тады никак.
Иначе вначале разрабатываем шаблоны. И пока не удастся исполнителей им следовать (уговорами, угрозами увольнения, отстрелом, ets.) про обработчик даже не думаем.

1-101 > В 7.7 формировали ТЗ, в 8.х можно формировать структуру. Тем паче, что Клиент ТЗ не знает.

SQLite можно припахать. Два шага: на первом создаем .db, на втором из 1С присасываемся к .db

(1) На клюшках любой дурак сделает.
(2) Ну, что-то типа правил заполнения создать можно. Но все равно, структура листов будет разная. Вот это и смущает.

по моим представлениям в таких задачах надо четко условится о спецификациях обмена, должно быть четко понятно, что находится в каком файле и как расположено. То есть полностью формализован интерфейс обмена или как VZ называет шаблоны. Тогда открываешь, читаешь вид, затем по виду берешь нужный алгоритм и разбираешь

либо читать как есть и потом парсить )

6-USSR > "потом парсить" - это просто откладывать неизбежное на другой этап. Алгоритм распознавания никак не изменится.

(7)я согласен )

Наличие четких спецификаций существенно повышает ответственность сторон, участвующих в процессе ) ID вида файла, в нем ID видов листов, в листе ID параметров и их значения

2(5) Формально правила будут примерно такие:
на каждом листе номенклатура с одинаковым набором параметров.
На листе первой строкой идут слово "артикул" и потом названия колонок (стандартизованные, названия параметров из внутренней документации берется (там есть чертежи всех этих комплектующих с ключевыми размерами и их обозначениями латиницей и цифирью, типа L - Длина (общая), LT12 - длина хвостовика первого присоединения (у всех)), DD31 - диаметр третьей присоединительной части, FX1 - смещение оси первой присоединительной части от базы по оси х и т.п.)
И со второй строки сами позиции и значения параметров без пропусков.
Конструктора так ведут свою документацию.
Проанализировать врукопашную файл без запросов - элементарно, а вот загнать его во внешний источник данных, чтоб внутри запроса его раскручивать и в отчеты можно было выводить - тут уже у меня затык в мозгах...

10-bma1 > Просто для каждого варианта таблицы делаешь отдельный файл .db - Type1.db, Type2.db ets. В каждой таблице свой набор полей.
Потом, при соединении просто пишешь:
ПараметрыСоединения = Новый ПараметрыСоединенияВнешнегоИсточникаДанных;
ПараметрыСоединения.СтрокаСоединения = "DRIVER=SQLite3 ODBC Driver;Database=" + Type1 + ";BigInt=1;";
ВнешниеИсточникиДанных.Type1.УстановитьОбщиеПараметрыСоединения(ПараметрыСоединения);
ВнешниеИсточникиДанных.Type1.УстановитьСоединение();
Запрос = Новый Запрос();
Запрос.Текст = "ВЫБРАТЬ
....
Как-то так ...

2(11) Заранее варианты не создать. Это же конструктора, они себе черта в ступе нарисуют и в свой файлик закинут. И там будет такой набор параметров, что никак заранее предусмотреть не можно.

12-bma1 > Ну, извини. У компа интеллекта нема. Для него слово "Диаметр" - просто набор байтов. Он их не понимает.

(13)По поводу диаметра не совсем соглашусь, потому что в прикладном решении, которое будет читать (это видимо 1С) можно завести словарь идентификаторов и программа будет прекрасно понимать, что "диаметр" это "диаметр", а не просто набор байтов

2(13, 14) Да ничего там расшифровывать не надо. Данные будут называться как колонки в экселе: LT12, FX2 etc. так пользователям и требуется.

Выход: написать "преобразователь", который будет превращать неформализованные мысли конструкторов в структурированные таблицы. И уже эти таблицы - давать на вход отчета.