Есть рабочая книга, настроенная, с макросами Visual Basic (куды ж мы без них )).
Есть несколько юзеров этой книги. Каждый хочет видеть только ему интересные столбцы, а не все.
Как это можно не сильно сложно сделать?

Вариант в лоб: разные книги для разных юзеров не очень хочется использовать, т.к. при изменении чего-нибудь (того же визуал бейсика, тьфу*3) придётся бегать по всем книгам и менять везде. Да и просто некрасиво.
Пока что оптимальный для меня вариант: дать одну книгу всем юзерам, и пусть сами после исполнения выбирают нужные им столбцы. Только вот он для юзера не оптимальный )))

Нет ли каких-нибудь свежих мыслей?

лобовое решение, которое возникло в изнасилованном праздником мозгу:

вывести в книгу тевкстовый элемент пользователь. В него будет вставляться системой текущий пользователь.

Ну а далее VBA в зубы и вперед - для каждого юзверя свои скрывалки...

даже можно сделать настроечные данные для скрытия столбцов для каждого пользователья на другом листе, его скрыть, макросом считывать те столбцы, которые надо показывать, все остальное - убирать....

Глобально
Вариант, конечно тоже.
Но хотелось бы что-то типа сохранённый ракурсов... Даже вот только что другая больная мысль возникла: понасоздавать ракурсов, а потом по кнопке VB остоединять текущий запрос и подсоединять нужный ракурс
Ужос, короче.

А что, если сделать ограниченный показатель. В нём ограничивать признак пользователя по всем юзерам, желающим анализировать сей показатель.

А ещё более правильней было бы не привязываться к конкретным пользователям в ограничении показателя, а ограничить кейфигары по типу пользователей.

В свою очередь пользователь при запуске раб. книги в окошке параметров выбирает свой тип (впоследствие можно персонифицировать это значение) и получает только нужные ему столбцы.

Классная идея!

Правда с реализацией не совсем понятно. Можно сделать опять-таки скрытый лист в книге где прописать соответствие типа пользователя и столбцам, которые нужны. Потом в VB скрывать по этой табличке. Вариант неплохой, не очень сложный, легко настраиваемый, но он будет работать только если показатели не разворачивать вертикально (в паре отчётов есть такое).

А вот как напрямую через запрос ограничить - чёт не совсем понятно. Добавить признак в куб не предлагать! А так вышло бы чертовски красиво!

Признак в куб добавлять всё равно придётся. Сомневаюсь, что у тебя уже есть в кубе признак "Тип пользователя"

Вообще-то я подразумевал, что решение будет в основном за счёт финтов на запросе. Не знаю на сколько навороченная логика на VBA реализована. Но пытался донести следующее:
1. показатель ограничиваем типом пользователя.
2. говорим скрывать нулевые столбцы

Получаем, что столбцы вообще не показываются ни при горизонтальной, ни при вертикальной развёртке.

Необхдимость в создавании скрытого листа с таблицей соответствия юзер-столбец отпадает в этом случае.

не прокатит. Тип пользователя надо будет заполнять при загрузке. Сразу возникает - а чем заполнять? как определить, какой тип пользователя проставлять?

А если вдруг одно и то же значение надо 2 группам пользователей, то что тогда?

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

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

э-э--э, не поведаете общественности, как это возможно при загрузке ?

Думаю, что теоретически можно
В правилах обновления для куба можно заполнять признак "вариант запуска". Но:
1. Это как-то криво само по себе
2. Достаточно сложно нагенерить записи по одной для каждого показателя, где бы был заполнен данный признак.
3. Если много показателей - куб разрастается до неприличных размеров. Плюс если в отчете разные столбцы основаны на одном и том же показателе, но по-разному зарестрикченном... Плюс что делать с расчетными показателями... Ужас.

Поэтому, имхо, как обычно, спасет вижуал басег со скрытой настроечной табличкой в книжке. Имхо самое безболезненное решение

Но сама идея была у таймера хорошая.

Господа, видимо НГ прошел не зря...

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

Вот сразу тут и возникает следующие грабли:
1. На основании чего надо заполнять тип пользователя ? то есть это либо hardcode либо какая то настроечная таблица
2. появление нового типа пользователя = перезагрузка данных( ну или гемморой с добавлением новых данных в куб)
3. если поток данных ОЧЕНЬ большой и достаточно много типаов пользователей - то скорее всего придет кирдык системе. во всяком случае такой вариант нельзя отрицать, ибо скорее всего при сайзинге на такое дело никто не закладывался
4. вели шанс,что загрузка может свалиться ( по таймауту либо по нехватке памяти). Причина - то что в правилах надо будет множить одну запись на типыпользовтаеля. Если приходит в пакете 20 тыс записей, а размножить надо на 100 типов - то не факт что система переварит 2 млн записей сразу. скорее всего она скажет досвиданье...

Вот так вот

Ну я же написал, что ТЕОРЕТИЧЕСКИ МОЖНО А новый год - это да, прошел не зря

По поводу хорошей идеи - имел ввиду типы пользователей (настраиваемые). Только способ реализации через запрос и загрузку данных в куб не подходит.

Превед EVK!
Ну и понаписали вы тут за ночь

Спасибо всем, кто откликнулся - видимо буду делать как и вчера думал.

Таймеру спасибо за идею!