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

Здравствуйте, KirBab, Вы писали:

KB>Столкнулся с проблемой: число пользователей БД превысило максимально допустимое значение. [skip]
Я, к сожалению, помочь тебе не могу. Не знаю специфики MSSQL в этих вопросах, хотя полагаю, что ты мог бы сделать нечто распределенное. Имею в виду возможность взвести несколько серверов для каждой из групп пользователей и организовать репликацию. Возможно надо перейди на более свежую версию сервера, мне почему-то думается, что ты пользуешься 7-кой. Предложения переходить на другие сервера не высказываю, полагаю, что это неприемлимо.
К чему же я начал писать свой ответ. Вот к чему. Не мог бы ты рассказать, как дошел до такой жизни? Все ли 16 с лишним тысяч пользователей активны? А какие объемы данных у тебя при этом?

Мне кажется, где-то утечка. В необходимость иметь 16379 активных сессий как-то не верится, как уже сказал VVP. Если это не утечка, возможно, надо пересмотреть архитектуру — например, сделать сервер приложений и работать через него. Ну или воспользоваться готовым Microsoft Transaction Server-ом и встроенным в него connection pooling-ом (сессия выделяется из пула).

Здравствуйте, Sergey Ten, Вы писали:

ST>Мне кажется, где-то утечка. В необходимость иметь 16379 активных сессий как-то не верится,

я думаю дело как раз не в кол-ве сессий, а юзеров: в sysusers для поля UID используется smallint.

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>я думаю дело как раз не в кол-ве сессий, а юзеров: в sysusers для поля UID используется smallint.

Да, пардон, неправильно прочитал вопрос. Но в этом случае можно попытаться насоздавать дополнительные базы данных и растащить по ним юзеров — sysusers копируется в каждую базу данных. Потом раздать права на изначальную базу со всеми таблицами.

Здравствуйте, Sergey Ten, Вы писали:

Или нескольким ФИЗИЧЕСКИМ пользователям дать одного ЛОГИЧЕСКОГО.
Там что 16379 различных прав доступа ?

Здравствуйте, adontz, Вы писали:

A>Или нескольким ФИЗИЧЕСКИМ пользователям дать одного ЛОГИЧЕСКОГО.

Это к автору первоначального вопроса. Не знаю, может, аудитить хочется каждого по отдельности или еще чего. А так, конечно, звучит логично.

Всем привет!
Я уже совсем не надеялся получить какой-либо ответ на свой "теоритический" вопрос, в одночасье ставший для меня практическим. Большое всем спасибо. Заканчивая, с лирикой, и отмечая присутствие модератора, хочу поблагодарить за классно оформленный сайт. Я вышел на него случайно...
Раз такое дело, попробую объяснить ситуацию поподробнее (если жена не выгонит из-за компа .
Скажу сразу: систему доступа проектировал не я, но я тоже не подозревал, что может возникнуть такая проблема. Представим, что есть некий условный центр, в нем все расписано по ролям. Все пользователи входят в одну из ролей. Дольше все построено на ХП, которые выполняются в зависимости от роли. Как обычно, объемы всего этого проекта были неизвестны и мы посчитали логичным идентификацию пользователей возложить на сервак. Пользователь по определенным правилам регестрируется и попадает в таблицу sysusers и в нашу таблицу пользователей, которая хранит специфические данные о нем и определяет дальнейшие связи с другими таблицами. Сразу скажу, что на критическом трафике, когда все юзеры ломятся в базу я клиетта не тестировал (первоночальное кол-во юзеров было около 5 тысяч). На больших объемах табличных данных система работала устойчиво. Я кое-что оптимизировал в ХП, но до теста когда идет одновременный коннект не дошел...
потом заказчик присылает нам Excel — файл со всеми юзерами своих филиалов и говорит, что их надо закачать в систему. Мы пишем скрипт и закачиваем... но как только smalint исчерпал себя, все, естественно, остановилось. Я конечно понимаю вопросы о том, что, а если все они (эти 16000) начнут ломиться на сервер... Честно скажу — не знаю что будет, хотя исходя из логики работы системы, думаю, что это маловероятно. Вот в силу всех этих обстоятельст у меня и возник вопрос про юзеров...
То, что систему доступа придется переделывать, это ясно и так, но в силу обстоятельств хотелось бы обойтись малой кровью. Кстати, использую я MS SQL Server 2000. Работаю на этой платформе довольно давно (лет 5, начинал с версии 6.5). Знаю, что у многих СУБД таких ограничений нет, но и сам не могу поверить, что это может быть такой проблемой. Понятно, что организованно что-то не так, но вопрос сейчас не в этом, а в том как это обойти.
Вариант с разделом баз напрошивается сам собой, но выглядит довольно проблематично для конкретной реализации. Может такой вариант приемлим: в каждой роли один юзер (доступ к ХП, следовательно менять не надо). Все юзеры конкретной роли (Role1) коннектятся под юзером (User1). Дальше, вместо проверки идентификации пользователя серваком я доступ беру на себя (в своей таблице где лежит инфа о юзерах). То, что все они идут под User1, не страшно, я их потом разведу, кто есть кто. Это как раз о теме последнего сабж о логических и физических пользователях. По крайней мере, для меня это переработка нескольких ХП и немного изобретательномти...
Ну, вот, написал все это и подумал: "А кому все это нужно?". Сам не знаю, может кому-то потом станет легче... Заранее спасибо, хотя бы за прочтение...
Про Титаник это не плохо...