8.х Вопрос про лицензии sql, на что влияет?

Добрый день, подскажите пожалуйста, у меня есть база данных на sql, на 10 пользователей лицензия, а допустим, если число привысит 10, что будет в этот момент? пользователь будет вбивать данны и они не сохранятся? или пользователя вышибет из базы?

Вы про лицензии 1С? Лицензии какие (программные, аппаратные, многопользовательские, однопользовательские)?
В общем случае 11-ый пользователь просто не сможет зайти в базу.

P.S. У самого же SQL никакой проверки нет.

то есть, можно было не покупать лицензию на 10 раб мест на sql, а купить просто лицензию на сервер??

а про лицензии самого 1с - это я в курсе.

Не можно. Технически работать будет, но правовой аспект останется.

P.S. Ну или для SQL использовать модель лицензирования "На процессор", тогда клиентские лицензии не нужны. Но для 10-ти пользователей "Сервер + CAL" должно быть дешевле.

"Процессорные лицензии" - нужно отдельно считать, т.к. их стоимость зависит от количества процессоров/ядер целевого сервера. И еще масса тонкостей возникает, например, если используются несколько серверов (продакшн + девелопмент + сервер отчетов) - то там еще большой вопрос при каком количестве пользователей модель лицензирования "по процессору" становиться выгодной.

Вы от Российского лицензионного отдела Microsoft "писем счастья" не получали еще? Нет? Вот лучше и не надо.
А так че, и сервера покупать не надо - на торрентах "за так" лежит.

Есть у меня в архиве один запросец на 1Ске... гарантированно кладет напрочь любой средне статистический промышленный сервер (на серверах с 2Тб ОЗУ не проверял) на базе всего то в 9Гб.
Причем мы это даже не специально, оно само как то так получилось (ну ошибся прогер, ну всякое ведь бывает). И только тыц -> 1.5-2 минуты тормоза -> 3 минуты вообще ничего не шевелиться -> АДМИНЫ! РЕБУТ!

Так что, всем и каждому советую - девелоп сервер держать отдельно, пусть и на более тухлом железе (тем более что как раз для девелопсервера можно применять недорогую лицензию MS SQL Server Developer Edition).

Но суть то проста:
Берем пять таблиц, всего по тысяче записей в каждой, все это дело некорректно соединяем и получаем:
N * M записей, при соединении 2х таблиц с N и M записей, 1 000 х 1 000 = 1 000 000 записей (полное соединение двух таблицы)
При присоединении еще одной таблицы, получаем уже 1 000 000 000
И так при соединении пятой таблицы, получаем уже 1 000 000 000 000 000 записей

А допустим одна запись результирующая - это 640 байт:
10 полей по 32 байта (Ссылки на справочники/документы, размер может быть и больше) и еще 6 полей чисел (допустим 32 байта) и текста 1 поле (допустим на 128 байт)
10*32 + 6 * 32 + 1*128 = 640 байт => вся результирующая таблица займет (должна была бы занять):
582 076.61 ТБ (терабайт).
Это даже не учитывая того, что каждое соединение можно оформить в виде временной таблицы, которая, если в запросе не уничтожать, "живет" на сервере до уничтожения запроса (т.е. еще и промежуточные итоги соединения таблиц А и Б, АБ и В, АБВ и Г...)


Конечно в нашем случае был не столь клинический случай, просто две таблицы (движений), 1 таблица - 2 234 000 записей, 2ая таблица - 2 788 000 записей, и полное соединение, вот только в поле соединения ошиблись, соединили по тому полю, которое гарантированно не совпадает (регистратор)

Вот запрос, если интересно: