Пожалуйста, помогите найти конвертор ирбисовского файла в Excel.

:)... скорее всего нигде... а как Вы себе представляете этот ехелевский файл? Как он должен выглядеть? Ну хоть примерно.

Что вы имеете в виду под "конвертером"? Для каких целей он вам нужен?

Многие издательства (небольшие редакционно-издательские отделы при ВУЗ-ах), книготорговые фирмы ведут свои каталоги (прайсы) в этом табличном редакторе. Фактически нужен конвертор туда/обратно, настриваемый. В форуме уже мелькала информация о подобного рода решении, но только в одну сторону (из редактора в ИРБИС). Если получится универсальное решение, то наверное оно будет полезно многим

Это уже интересно. Рас проблема возникла, значит у кого-то должен быть пример такого ехель-файла. Можно на него взглянуть?

Пример такого файла можно взять на сайте любого серьезного книжного магазина. Называется "прайс" :)). Или в отделе комплектования куда такие прайсы валятся каждый день по электронке. Типичная их структура (плюс-минус) такая:
Автор(ы); Заглавие; Издательство; Год; Цена; Страницы; Раздел знаний; ISBN (возможно)
&nbspace т.е.
700(701)^a; 200^a; 210^c; 210^d; 10^d; 215^a; 60; 10^a

Загрузить это в ИРБИС можно двумя путями:
1. Штатно: преизвратив XLS в поглощаемый ИРБИСом TXT (причем, имхо, без макросов это сделать ну практически невозможно) и далее согласно документации на БД Предварительного заказа книг. Мученически кривясь и тяжело вздыхая. :/
2. Прямо из XLS в нужную (точнее НЕНУЖНУЮ) БД, используя Isis32.dll. Без актуализации, ФЛК и прочего. Гордо выпячивая челюсть :)

Выгрузить в Exel, гораздо проще:
1. Написав выходной формат, где перечисленные в прайсе поля разделяются табуляцией (либо чем-нибудь более экзотическим), а записи - возвратами каретки. Выгрузить все это в rtf, открыть, сохранить как txt и спокойно открывать в EXEL.
2. Аналогично загрузке по второму пункту. Приговариая "Ай да, я. Ай, да сукин сын, я еще и поиском в isis32.dll рулю..." :)

На мой вкус для первого больше подходит 2 путь, для второго - первый. но в любом из вариантов без минимума знаний хотя бы в VBA и языке форматирования ну никак не обойтись.
Косное решение для этих таких задач получиться не может, поскольку сами такие прайсы неунифицированы, а следовательно набор загружаемых/выгружаемых полей вариабелен. Для обычного пользователя ИРБИС (даже при наличии такого решения) весь процесс застопориться на определении меток полей/подполей (тут действительно медвежью улугу оказывает их скрытие в интерфейсе ИРБИСА, о чем писалось уже не раз). Что можно обойти разработкой человеколюбивого справочника на базе default.ws и примкнувших к нему. Причем еще возникает нетривиальная ситуация загрузки нескольких полей exel в одно/несколько isis (210^d&^c, например или колонок с авторами в XLS может быть несколько), что однозначно должен указывать неспоредственный пользователь. Т.о. тут однозначно огромную роль играет разработка интерфейса и это уже получается "продукт".
Теперь пример мыслей некоего отвлеченного :) программиста по этому поводу: "Создавать продукт если нет достаточного количества заявок, т.е. реальной в нем необходимости и уверенности в том, что его, как минимум, протестируют и, как оптимум, регулярно будут использовать в повседневной работе и не один-два, а хотя бы десяток пользователей, никакого интереса нет. Лично мне - для моих внутренних целей хватит и собственного репозитория и опыта. Пусть он и выглядит неприглядно и надо все время в код залазить, но мне так проще и удобнее".
См., например, [irbis.gpntb.ru] в части PS. Ведь не напишет же, пока не сформулируется грамотное ТЗ (либо кем-то, либо, скорее всего им самим).

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

да Бога ради, я переводами торговать не собираюсь :). Це ж к общему благу

Действительно, все больше АБИС используют xls или как внутренний формат, хотя бы частично (например, тезаурусы в МАРК-SQL и еще что-то в "Буки"), или как выходной (например, недавно появился такой конвертор для "Библиотеки 5.x")
…и это именно конвертор lexel.con, хотя довольно странный. Цитата из инструкции к нему:
«Чтобы загрузить записи в формате XLS (Excel) в каталог Читатели необходимо:
1. Зайти в Excel и открыть файл primer.xls.
2. Сохранить файл как Текст (MS-DOS) - primer.txt.
3. Выйти из Excel и запустить программу Библиотека 5.x…»

ВЫВОД: нужно включить в число входных (и даже выходных) форматов RTF, HTML, XML, XLS, MDB и PDF.
Существующие примеры:
1. Часть из перечисленных форматов являются входными в ИРБИС64, но только в качестве полных текстов.
2. HTML — выходной формат (в том числе по умолчанию) в WinISIS и МАРК-SQL.
3. Существуют утилиты ISIS2XML и ISISLEX Generation d’un lexique (из семейства Outils Isis). Назначение первого ясно из названия, а второй, как тоже легко понять из названия (даже совершенно не зная французского), имеет отношение к лингвистическому обеспечению, т.е. к словарям, которые он выгружает (генерирует), в том числе в MDB. Следовательно, ISIS и Access не враги!



Отправка отредактированного (22-03-05 16:55)

Косное решение для этих таких задач получиться не может, поскольку сами такие прайсы неунифицированы, а следовательно набор загружаемых/выгружаемых полей вариабелен. Для обычного пользователя ИРБИС (даже при наличии такого решения) весь процесс застопориться на определении меток полей/подполей (тут действительно медвежью улугу оказывает их скрытие в интерфейсе ИРБИСА, о чем писалось уже не раз). Что можно обойти разработкой человеколюбивого справочника на базе default.ws и примкнувших к нему. Причем еще возникает нетривиальная ситуация загрузки нескольких полей exel в одно/несколько isis (210^d&^c, например или колонок с авторами в XLS может быть несколько), что однозначно должен указывать неспоредственный пользователь. Т.о. тут однозначно огромную роль играет разработка интерфейса и это уже получается "продукт".

Полностью согласен со всеми предложениями о человеколюбивом инрефейсе и т.д.

Теперь пример мыслей некоего отвлеченного :) программиста по этому поводу: "Создавать продукт если нет достаточного количества заявок, т.е. реальной в нем необходимости и уверенности в том, что его, как минимум, протестируют и, как оптимум, регулярно будут использовать в повседневной работе и не один-два, а хотя бы десяток пользователей, никакого интереса нет. Лично мне - для моих внутренних целей хватит и собственного репозитория и опыта. Пусть он и выглядит неприглядно и надо все время в код залазить, но мне так проще и удобнее".
См., например, [irbis.gpntb.ru] в части PS. Ведь не напишет же, пока не сформулируется грамотное ТЗ (либо кем-то, либо, скорее всего им самим).

Если весь вопрос состоит в необходимости найти тестеров, то я готов их предоставить, причем в организованном виде, т.е. с эл. адресами Ф.И.О. и т.д. В последующем можно говорить и о попытке коммерческого использования такого продукта. Это я заявляю, как дистрибьютор системы по Украине, причем можно говорить и о продаже для пользователей системы и о продаже издательствам (книготорговцам).. Понятно, что деньги небольшие, но это второй шаг...

Так, что жду от вас ответа.....

Я недавно увидел ИРБИС и пока не знаю, может вопрос мой глуп как мир, но как сделать так, чтобы выходные формы печатались в ёкселе. Т.к. на работе загрузили одной бодягой. Нужно для определенного КСУ сделать выходную форму, чтобы вводить только № КСУ, а он считает все наименования, кол-во экземпляров, а также суммы, но суммы не по КСУ, а пересчитывает каждую жалкую книжонку.
Может кто сталкивался с данной проблемой, помогите, чем можете, please!!!. Заранее благодарен.