Александр Иосифович, а можно несколько предложений к 2007.1? :)

1. Вынести все параметры в серверный ini-файл. В клиентском оставить только ServerIP, ServerPort, User, Common, добавить два новых - AutoLogonName, AutoLogonPass (Для автологона на сервер), а также оставить секцию context. При наличии секции - данные из нее имеют больший приоритет и вход выполняется именно с использованием этой секции. При этом хотелось бы что бы клиентский ini-файл можно было делать ReadOnly (Кроме тех, разумеется, где используется context). Желание вынести все параметры на сервер понятно - слишком трудно уже настраивать такое количество настроек для нескольких АРМ в ТАКОМ количестве файлов.Напрмиер, только для 1 комплектатора, имеющего доступ к АРМ Комплектатор, Книгообеспеченность и Каталогизатор придется настраивать 8 ini-файлов. (по 3 на комплектатор и ко и 2 на каталогизатора)

2. Сделать возможность подключать к ини-файлам другие файлы (include) - например, так:
@komplekt.ini
И в месте вставки используются данные из файла komplekt.ini.
Удобство этой функции переоценить трудно - это, фактически, возможность создавать ГРУППЫ профилей. Тогда при внесении изменений в файл komplekt.ini эти изменения будут использоваться сразу всей группой пользователей, в ini-файлах которых есть ссылка на файл komplekt.ini
Конечно тут есть сложность при изменении кода - ведь вам придется отслеживать какой параметр в каком файле находится, что бы при сохранении ini не затирать ссылку. Но получаемое удобство в настройке (IMSHO) того стоит... Вообще, стараюсь при каждой установке новой ВЕРСИИ (именно версии а не апдейтов) использовать чистый дистрибутив, пересоздавая всех пользователей - ведь часто в ini-файлы вводятся новые параметры, дающие новые возможности и их хотелось бы использовать. При 40 сотрудниках, имеющих доступ к 1-6 АРМ эта работа превращается в... А так, практически все параметры кроме trwbq private и desktop можно было бы выносить в такие файлы...

3. Предлагаю для всех файлов в базе сделать еще такую возможность: Если существует такой файл с добавленным расширением usr, то читать имено его.
Например:
В дистрибутиве есть файл fio.mnu. Если рядом с этим файлом положить файл fio.mnu.usr, то данные бы читались именно из fio.mnu.usr, несмотря на то что клиентом запрашивается файл fio.mnu. Думаю, в ИРБИС-64 такое достаточно легко реализовать - ведь там функция чтения файла централизованная?
Очень полезно было бы при обновлениях системы - достаточно у себя хранить набор usr-файлов и можно не бояться что при обновлении системы будут стерты "родные" справочники, WSS и т.д. Да и администраторам будет сразу понятно какие файлы они меняли, а какие не менялись по сравнению с дистрибутивом...



Редактировано 1 раз. Последний раз 04.04.2007 10:01 пользователем Михайленко Илья.

Ну вот. Опять (уже в какой раз, Александр Иосифович?) всплывают идеи, высказанные еще 2 года назад. Может пора прислушаться?

Про п. 1 не раз я говорил. Даже где-то была дискуссия. Не помню чем кончилась, но воз и ныне там.
По поводу п.2: разумно, но думаю не стоит. Требуется сделать редактор ini-файлов более функциональным. Мы на позапрошлом еще либкоме с Константином Олеговичем вроде сошлись во мнении, что это нужно. Но опять же ничего не сделано.
п.3 - ОЧЕНЬ разумное решение!!! Думаю это тот самый выход, который я ищу уже полтора года. Вместо слежения за изменениями, их проще вынести в отдельные файлы. Реализовать это совершенно не сложно (кажется мне, что там очень много копи-паста будет). Но польза действительно будет огромная.

Вот и отличный повод провести первый опрос :)
п.1 - присоединяюсь безоговорочно поскольку также неоднократно выражал эту просьбу;
п.2 - интересно, конечно и полезно, но я тоже согласен с М.Паневым, что критически необходим более функциональный профайлер (правда если это сделает ЭБНИТ "я буду плакат")
п.3 мне кажется это несколько надумано... Тут весь вопрос с протоколировании своих действий и не более, по моему еще более скромному мнению :)

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

В протоколировании? Так это не просто вопрос. Это проблема. Причем серьезная. Такое решение было бы очень кстати.

Насчёт протоколирования -- согласен. Вещь проблематичная, особенно, если приходится накатывать с нового дистрибутива на рабочую версию, которую полгода подправляли то там, то здесь. Зачем вести гроссбухи, если уж пользуемся компьютером, а не абаком? К тому же там не пара файлов, которые легко отследить.

По поводу переноса параметров из клиенского INI-файла в серверный...
Укажите КОНКРЕТНЫЕ параметры клиентских INI-файлов, которые "осложняют" Вам жизнь как администраторам...

ВСЕ, кроме строк отвечающих за подключение. И я об этом уже писал: в случае если все будет вынесено на сервер, я смогу положить клиентскю часть в общедоступную папку и обновлять ее одномоментно, а не бегать по сотне машин "ногами". Тогда как сейчас иного выхода нет - главным образом из-за PRIVATE, но и все остальное (настройка интерфейса, размеры КК и проч.) тоже немаловажно. Ведь это ИНДИВИДУАЛЬНЫЕ настройки пользовательской среды.

Кстати, [DESKTOP] не фиксирует позиции панелей :( Т.е. размеры рабочих областей он запоминает, видимость панелей тоже, а вот позиции для панелей - нет

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Действительно. Вопрос переноса ВСЕ не индивидуальных параметров встал еще когда появилась 4.2 64. По моему так на клиенте даже PRIVATE быть не должно. Только параметры соединения. Есть пользователь на сервер и ВСЕ. Сейчас получается, то для 10 клиентов необходимо на сервере 10 ини + на клиенте 10 ини. Это в корне не правильная политика.

Я еще раз спрашиваю - КАКИЕ КОНКРЕТНО ПАРАМЕТРЫ ВАМ ПРИХОДИТСЯ МЕНЯТЬ У КЛИЕНТА.
PRIVATE тут ни при чем - эти параметры идут из клиентского режима НАСТРОЙКА.

Попробую...
Хотя проще просто ВСЕ параметры хранить на сервере, а читать только ServerIP, ServerPort И главное - дать возможность сделать его READONLY. Тогда для ВСЕХ клиентов и АРМов он будет одинаков.
И мы избавимся, наконец-то от множества КЛИЕНТСКИХ ini, которые необходимо создавать для каждого АРМ и каждого клиента. (а для некоторых АРМ и по 2).
Какие параметры этому мешают сейчас? Попробую кратко пробежаться хотя бы по cirbisc...

CIRBISC.ini

[Main]
User= // Смена лицензии/названия (например с 45 до 50 клиентов)
FontName=
FontCharSet=
FontSize=
WaitNoModal=
WebServer=
WebCgi= Бывает что и с сервера на сервер переезжает.
Scalable=
Common=//эт то же к лицензии.
HLPFILE=он разный для разных АРМ.
Workdir= У нас - сетевая папка (для каждого отдела своя), люди, бывает, переходят из отдела в отдел...
DictionPortion= регулируется в зависимости от нагрузки и сетевых возможностей.
KKKDEFAULTWIDTH=Эти правятся в зависимости от принтеров. Два принтера уже делают невозможным задание "единых параметров для всех"
KKKDEFAULTHEIGHT=
KKKDEFAULTTOP=
KKKDEFAULTLEFT=
KKKDEFAULTBOTTOM=
KKKDEFAULTRIGHT=
KKKOrientation=
KKKFDEFAULTWIDTH=
KKKFDEFAULTHEIGHT=
KKKFDEFAULTTOP=
KKKFDEFAULTLEFT=
KKKFDEFAULTBOTTOM=
KKKFDEFAULTRIGHT=
KKKFOrientation=
KKKSizeMeasure=
OperHint=
WSSWORDWRAP=
SHOW_WAITING_IN_SECOND=это регулируется в зависимости от качества сети а в разных корпусах и уголках города скорость до основного сервера очень разная...
DictionSence=
DisplaySence=
ICONS=
CustomDict=
LINKINNEWWINDOW=
DebilPrefix=
KATKO=
SVKADDIND=
SVKADDEX=

[Display]
MaxBriefPortion=Редко, но сети все же разные...

[PRIVATE] Ну, тут точно у каждого свое. И делать их одинаковыми для всех клиентов смысла нету. Относится ко всей секции. Этому точно место на срвере.
PRPARNAME1=
PRPARVALUE1=
PRPARNAME2=
PRPARVALUE2=
PRPARNAME3=
PRPARVALUE3=
PRPARNAME4=
PRPARVALUE4=
PRPARNAME5=
PRPARVALUE5=
PRPARNAME6=
PRPARVALUE6=
PRPARNAME7=
PRPARVALUE7=
PRPARNAME8=
PRPARVALUE8=
PRPARNAME9=
PRPARVALUE9=
ETR=
FIO=
KSU=
NA=
KSUD=
KKC=
FPC=
KKE=
KKI=
FPI=
KKK=
FPK=
KKA=
FPA=
KKO=
KKR=
KKN=
FPN=
KKP=
FPP=
KKS=
FPS=
EEE=
3=
KKZ=
KS2=
PKS2=
PROVFOND=
PRFDDAT=
PRFDMHR=
ATH=
SKSG=
EKP=

[DESKTOP] Параметры экрана то же у всех разные, потому сделать их одинаковыми для всех то же не удасться...
Width=
Height=
MainMenu=
MainMenuLeft=
MainMenuTop=
DBContext=
DBContextLeft=
DBContextTop=
Entry=
EntryLeft=
EntryTop=
DBOpen=
DBOpenLeft=
DBOpenTop=
Search=
SearchLeft=
SearchTop=
Display=
DisplayLeft=
DisplayTop=
Service=
ServiceLeft=
ServiceTop=
Lists=
ListsLeft=
ListsTop=
DisplayHeight=
DictionWidth=
DisplayFullWidth=
ListsWidth0=
ListsWidth1=
MainMenuFloating=
DBContextFloating=
EntryFloating=
DBOpenFloating=
SearchFloating=
DisplayFloating=
ServiceFloating=
ListsFloating=
FLYUNICODE=
FLYUNICODELEFT=
FLYUNICODETOP=
FLYUNICODEWIDTH=
FLYUNICODEHEIGHT=
SPELLING=
DICTIONMOVING=


-------------------------
К этому хотелось бы добавить предложение - два параметра, которые бы регулировали ИСПОЛНЕНИЕ ini-файла. Один параметр - ссылка на ini с общими параметрами(1), который читается ДО основного ini, второй - ссылка на файл, который читается ПОСЛЕ основного(2). АРМ при запуске последовательно читает и применяет эти 3 ini-файла(1-й, свой родной и 2-й). В дальнейшем спокойно работает в своем обычном режиме со своим ini-файлом.
Таким образом можно будет: 1. Задавть параметры "по умолчанию", 2. Задавать неизменяемые параметры. АРМ спокойно работает со своим ini-файлом. Зато при 1-м запуске можно создать ini всего с 2 параметрами - остальные АРМ сохранит при выходе. А при каждом запуске у АРМ будет возможность прочитать данные из 2-го файла (которые устанавливаются, к примеру, на группу и переопределяют параметры из 1 и основного ini-файлов - т.е. "навсегда" (до тех пор пока админ не решит иначе)). Вот и получаются и "профиль по-умолчанию" и "постоянные параметры" и "параметры на группу" и т.д...
Как сделать еще проще - пока не придумал :)

Alio написал(а):
-------------------------------------------------------
> Я еще раз спрашиваю - КАКИЕ КОНКРЕТНО ПАРАМЕТРЫ
> ВАМ ПРИХОДИТСЯ МЕНЯТЬ У КЛИЕНТА.

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

> PRIVATE тут ни при чем - эти параметры идут из
> клиентского режима НАСТРОЙКА.

А вот это как раз очень критично - и я писал об этом не раз. Проверено, что эта секция в клиентском ини имеет приоритет перед аналогичной серверной, как наверняка и остальные, - т.е. если у клиентского ини параметр не пуст, то используется именно он, что бы там на сервере не лежало. Именно по этой причине я, например, вынужден сейчас использовать для хранения ФИО секцию MAIN на сервере и переписывать соответственно autoin, потому что мне категорически НЕ НУЖНО, чтобы пользователь произвольно менял сведения об ответственном за изменения в БД, в не зависимости от того под каким логином он зашел. Ну и т.д и т.п.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Наконец-то поднялся и этот вопрос на форуме.

Давно уже хочется, чтобы все параметры вынеслись на сервер. В серверные Ини. Так что полностью поддерживаю Максимов!
Расписывать не будем, что именно приходится менять у клиента, но приходится, иногда и очень много. И чтобы не делать двойной работы, желательно все вынести в серверную часть. В клиентском ини, оставить то, что написано в первом посте.

Ярославская ОУНБ им. Н.А. Некрасова

Примите и наш голос в поддержку переноса параметров на сервер. Для большой библиотеки очень актуальная проблема. Это сильно облегчит нашу жизнь при смене версий.

Согласен с переносом всех ФУНКЦИОНАЛЬНЫХ параметров из клиентских в серверные INI-файлы
Но в любом случае - клиентские INI-файлы не перестанут быть ЛИЧНЫМИ, т.е. их нельзя будет "зашарить" и использовать нескольким клиентам.
(Никому ведь в голову не приходит "зашаривать" сугубо клиенские приложения (хоть Total Commander, хоть ACDSee) и их настройки для нескольких клиентов - каждому ставится индивидуально)
Другое дело - в клиенстском INI-файле не останется параметров, которые нуждались бы в ВЕДЕНИИ.

Решение этой проблемы осложняется лишь одним - сохранением преемственности...

Alio написал(а):
-------------------------------------------------------
> Согласен с переносом всех ФУНКЦИОНАЛЬНЫХ
> параметров из клиентских в серверные INI-файлы
Какие параметры Вы относите к НЕФУНКЦИОНАЛЬНЫМ, т.е. тем, что должны отаваться на стороне клиента безусловно?

> Но в любом случае - клиентские INI-файлы не
> перестанут быть ЛИЧНЫМИ, т.е. их нельзя будет
> "зашарить" и использовать нескольким клиентам.
> (Никому ведь в голову не приходит "зашаривать"
> сугубо клиенские приложения (хоть Total Commander,
> хоть ACDSee) и их настройки для нескольких
> клиентов - каждому ставится индивидуально)

Аналогия тут не совсем понятна, ведь АРМы ИРБИСа не "сугубо клиентские приложения"... Хотя в общем ясно, что CONTEXT останется на стороне клиента.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Безусловно на стороне клиента останутся параметры секции CONTEXT DESKTOP, а также некоторые другие, которые не нуждаются в ведении со стороны Администратора (м.б. секция PRIVATE и параметры ККК... - но это еще вопрос)

Ну Александр Иосифович... Вы меня просто без ножа режете :) - взяли и перечислили собственно весь клиентский ини. Да как раз то что НЕ НАДО вести АДМИНИСТРАТОРУ и надо вынести в серверную часть. Именно в этом заключался наш коллективный "вопл"

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP



Редактировано 1 раз. Последний раз 20.04.2007 11:38 пользователем Куделя.

Так идея-то была не в том, чтобы у клиентов отобрать всё и расшарить, организовав групповые политики (что тоже было бы неплохо), а чтобы была возможность задавать перекрываемые клиентским .ini параметры, которые задаются на стороне сервера. Я так понял предложение. Нет?

Куделя написал(а):
-------------------------------------------------------
> Ну Александр Иосифович... Вы меня просто без ножа
> режете :) - взяли и перечислили собственно весь
> клиентский ини. Да как раз то что НЕ НАДО вести
> АДМИНИСТРАТОРУ и надо вынести в серверную часть.
> Именно в этом заключался наш коллективный "вопл"

чТО вЫ ИМЕЕТЕ ПРОТИВ ТОГО, ЧТО CONTEXT и DESKTOP остаются в клиентском INI-файле?

Да в общем-то ничего. Только я не понимаю, почему не доработать протокол, чтобы можно было не расшаренный ини использовать а гонять трафик по протоколу внутреннему. Необходимо, чтобы ВСЕ настройки были на сервере. Тогда ИНДИВИДУАЛЬНЫЕ ини нужно будет задать(чит. создать) только на сервере, а не создавать еще кучу копий на клиенте.
Александр Иосифович. Я никак не могу понять ваше упорное стремление держать настройки на клиенте. При существующей схеме авторизации это просто не рационально. В конце концов можно настройки каждого пользователя вынести в базу Ирбис :), а не использовать ини-файлы :). Тоже, кстати, интересная идея. Один пользователь - одна запись.

Я окончательно потерял смысл этого обсуждения.
Я сказал, что оставляю в клиентском INI-файле только параметры секций CONTEXT и DESKTOP, которые
- безопасны (с точки зрения вмешательства клиента)
- не нуждаются в ведении со стороны администратора (т.е. администратору не надо "бегать"...)

(Ликвидировать совсем клиентский INI-файл нельзя (он нужен хотя бы для ServerIP и ServerPort), т.е. файл такой у клиента все равно должен быть и обновлять его не надо по версиям - тогда почему в нем нельзя сохранять параметры, о которых сказано выше)

КАКИЕ ВОЗРАЖЕНИЯ?

Так проблемы-то тут 2:
первая - бегать - обновлять
вторая - для 10 пользователей, если они за одним компьютером, нужно создать 10-50 ини на сервере и столько же на клиенте. Я говорю про решение второй проблемы. А вы предложили решение первой.

Никаких. Просто Вы сказали PRIVATE (не к ночи он будь помянут) и KKK - на что я автоматически сделал стойку.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Панев Максим написал(а):
-------------------------------------------------------
> Так проблемы-то тут 2:
> первая - бегать - обновлять
> вторая - для 10 пользователей, если они за одним
> компьютером, нужно создать 10-50 ини на сервере и
> столько же на клиенте. Я говорю про решение второй
> проблемы. А вы предложили решение первой.

В случае нового клиентского INI-файла - почему 10 Ваших клиентов за одним компьютером не могут пользоваться одним клиентским INI-файлом?

Могут, а как же приват + Для каждого свои расстановки рабочих областей (читать секция DESKTOP) и т.д. и т.п.

Панев Максим написал(а):
-------------------------------------------------------
> Могут, а как же приват + Для каждого свои
> расстановки рабочих областей (читать секция
> DESKTOP) и т.д. и т.п.

секции PRIVATE не будет, а с изменчивостью DESKTOP можно вполне смириться (как мирятся с DESKTOP любого другого приложения - если за одним компьютером работает несколько человек не меняя юзера Windows)

В связи с перераспределением параметров между клиентским и серверным INI-файлами можно подумать об идее ВЛОЖЕННЫХ INI-файлов (на стороне сервера) - это, действительно, позволит упростить работу администратора

Так вот да. Эту идею полностью поддерживаю...

> В связи с перераспределением параметров между
> клиентским и серверным INI-файлами можно подумать
> об идее ВЛОЖЕННЫХ INI-файлов (на стороне сервера)
> - это, действительно, позволит упростить работу
> администратора


Если вложенность возможно организовать - это будет фантастически хорошим нововведением. Хотя я плохо представляю как АРМ будет писать параметры во вложенные ini, и как ему запретить перезаписывать те или иные общие параметры. Одно решение я уже предлагал: добавить - два параметра, которые бы регулировали ИСПОЛНЕНИЕ ini-файла. Один параметр - ссылка на ini с общими параметрами(1), который читается ДО основного ini, второй - ссылка на файл, который читается ПОСЛЕ основного(2). АРМ при запуске последовательно читает и применяет эти 3 ini-файла(1-й, свой родной и 2-й). В дальнейшем спокойно работает в своем обычном режиме со своим ini-файлом.
Таким образом можно будет: 1. Задавть параметры "по умолчанию", 2. Задавать неизменяемые параметры. АРМ спокойно работает со своим ini-файлом. Зато при 1-м запуске можно создать ini всего с 2 параметрами - остальные АРМ сохранит при выходе. А при каждом запуске у АРМ будет возможность прочитать данные из 2-го файла (которые устанавливаются, к примеру, на группу и переопределяют параметры из 1 и основного ini-файлов - т.е. "навсегда" (до тех пор пока админ не решит иначе)). Вот и получаются и "профиль по-умолчанию" и "постоянные параметры" и "параметры на группу" и т.д...

Очень хорошее и развернутое обсуждение получается. Проблема действительно назрела.
Попробую еще раз обосновать необходимость почему клиентские ini-файлы должны содержать только ip и порт и быть при этом readonly.
Система в библиотеке развивается очень динамично - у меня, кпримеру, уже сейчас 40 пользователей-сотрудников. 80 серверных ini-файлов и 94 клиентских расшареных ини-файлов. Почему бы мне не хранить клиентские ini-на клиентских машинах? Потому что если у меня сотрудник переходит из подразделения в 6 корпуса в подразделение 10 корпуса, мне придется ехать в 6 корпус, чтобы забрать настройки пользователя, после чего ехать в 10 корпус что бы там эти настройки сложить. И это при наличии сети между корпусами. Не смогу я объяснить библиотекарю, что ему, находясь в 6 корпусе нужно такие-то файлы скопировать на сервер во 2 корпусе, после чего приехав в 10 корпус взять эти файлы и скопировать их себе на локальную машину. Да еще при этом мне нужно будет удостовериться что ярлык, который передастся ему средствами домена при логине в 10 корпусе будет указывать на нужный локальный путь. Плюс к этому обновление клиетской части будет означать поездку по всем корпусам, во все подразделения для обновления соответствующих исполняемых файлов. Если учесть, что доступ к АРМ Читатель мы сейчас начинаем распространять на факультетах и их классах, а так же что доступ к АРМ Книгообеспеченность в режиме ReadOnly так же просят факультеты, то естесственное желание настроить у клиентов все так, что бы все настройки сводились к созданию на рабочем столе ярлыка. Что бы обновление системы проходило централизовано. А учитывая, что люди на тех же ккафедрах работают разные, то желательно что бы и все файлы с этой "шары" были ReadOnly. Иначе первый же "шутник", удаливший все что может в этой шаре приведет к полной неработоспособности системы на местах.
А что делать, если, к примеру, для проведения тех. работ а сервере ИРБИСА (на железяке) мне потребуется временно перенести работу на другой сервер? При этом, т.к. "лишних" серверов нету, то ИРБИС переезжает на сервер, уже имеющий свой ip-адрес и имя. Если бы ini-файл клиентский лежал бы на файл-сервере и содержал бы только информацию о ip и номере порта, то вся работа бы заключалась во внесении изменений в этот файл ночью, когда АРМ выключены и переносе сервера на другую физ. площадку на следующее утро я бы уже мог спокойно проводить сервисные работы и клиенты даже не заметили бы что работают с другим физическим сервером. А какой объем работы мне необходимо будет выполнить сейчас? Проехаться ночью по всем корпусам и подразделениям? Это, по-моему, абсолютно не реально... Если клиентские ini лежат на шаре, то за ночь нужно будет поменять, к примеру, 150 ini-файлов на сервере. Админ то же человек. Ему еще и спать иногда хочется :)

Потому и есть такая огромная просьба - ВСЮ параметрию клиентских мест брать с сервера, оставляя клиенту только информацию о ip и номере порта.

И, кстати, ini-файл с контекстом можно хранить на клиенте - его имя ведь создается исходя из параметра основного ini файла (ForCirbisIni). Что может быть проще, чем создать такой ini, запустить АРМ с этим локальным ini, после закрытия АРМ удалить этот ini. Главное не забыть, что в клиентский ini-файл АРМ ничего писать не может :) поэтому удалять такой ini надо из запустившего АРМ (тем более, он все равно сейчас ждет завершения).
Только папку для хранения этого ini, конечно, нужно использовать другую. Это ведь, фактически, временный файл - и место ему в %TEMP%.

PS. Пишу много и подробно потому как действительно уже "наболело"

Предлагается вот такая схема ВЛОЖЕННЫХ INI-файлов.

Вложенный ini-файл указывается в исходном ini-файле в виде ПУСТОЙ секции

[@<имя_ini_файла>]

Местоположение вложенного ini-файла внутри исходного НЕ ИМЕЕТ значения.

В случае ОДНОИМЕННЫХ параметров в ОДНОИМЕННЫХ секциях приоритет за ИСХОДНЫМ INI-файлом.

Т.е. если создать следующий ЛИЧНЫЙ INI-файл Каталогизатора


[@irbisc]

[MAIN]
FontName=Times New Roman
DefaultDB=RDR


ТО получим профиль пользователя, который отличается от СТАНДАРТНОГО только двумя параметрами...