Существует предел в 2100 параметров, которые могут быть переданы серверному запросу Sql, то есть через ADO.Net, но каковы документированные ограничения для других общих баз данных, используемых разработчиками .Net - в частности, меня интересует:
Кто-нибудь знает?
Oracle: 64 000 Источник
MySQL:
MySqlCommand.Prepare() (и указывая IgnorePrepare=false в строке подключения), тогда существует ограничение в 65 535 параметров (поскольку num_params должен умещаться в два байта).PostgreSql: EDIT: 34464 для запроса и 100 для функции в соответствии с ответом Магнуса Хагандера (ответ скопирован здесь, чтобы обеспечить единую точку отсчета)
SqlLite: 999 (SQLITE_MAX_VARIABLE_NUMBER, который по умолчанию равен 999, но может быть уменьшен во время выполнения) - И для функций по умолчанию установлено 100 параметров. См. Раздел 9 документации по временным рамкам.
Правильный ответ для PostgreSQL выглядит как 34464, когда речь идет о связанных параметрах с запросом. Ответ 100 по-прежнему корректен для количества параметров для функции.
В jOOQ мы обошли эти ограничения, добавив значения привязки, как только мы достигнем соответствующего числа для каждого поставщика. Числа задокументированы здесь. Не все числа обязательно являются правильными в соответствии с документацией поставщика, мы обнаружили их опытным путем методом проб и ошибок в JDBC. Они (без привязки их к конкретной версии):
Другие базы данных, похоже, не имеют каких-либо ограничений - по крайней мере, мы их еще не обнаружили (хотя не смотрели далеко за 100000).
Проводной протокол PostgreSQL использует 16-битные целые числа для подсчета параметров в сообщении связывания (http://www.postgresql.org/docs/9.4/static/protocol-message-formats.html).
Таким образом, протокол PostgreSQL не позволяет использовать более 65535 параметров для одного оператора. Это нормально, чтобы отправить одну команду ado.net с двумя операторами, каждый из которых имеет 65535 параметров.
На мой взгляд, вопрос MySQL имеет два ответа. Подготовленный протокол оператора определяет 2-байтовое короткое число со знаком для описания количества параметров, которые будут получены с сервера. Сначала клиент вызывает COM_STMT_PREPARE, для которого он получает ответ COM_STMT_PREPARE в случае успеха.
Документация для ответа гласит:
Если num_params> 0, то последуют следующие пакеты:
Блок определения параметров
num_params*Protocol::ColumnDefinition
EOF_Packet
Учитывая, что num_params может быть максимум 2 ^ 16, из этого следует, что это предел параметров, и поскольку у моей компании есть собственный драйвер MySQL, мы решили следовать этому правилу при его реализации, и исключение выдается, если предел равен превышены.
Однако COM_STMT_PREPARE фактически не возвращает ошибку, если вы отправляете больше этого количества параметров. Значение num_params на самом деле просто 2 ^ 16, и после этого последуют другие параметры. Я не уверен, что это ошибка, но в документации к протоколу это поведение не описывается.
До тех пор, пока у вас на стороне клиента есть возможность узнать количество параметров (если хотите, client_num_params), вы можете реализовать свой клиент MySQL таким образом, чтобы он client_num_params увидеть client_num_params x Protocol::ColumnDefinition. Вы также можете следить за EOF_Packet но он действительно отправляется, только если CLIENT_DEPRECATE_EOF не включен.
Также интересно отметить, что после num_params есть зарезервированный байт, указывающий, что разработчики протокола, вероятно, хотели сделать это 24-битное число, допускающее около 8,3 миллиона параметров. Это также потребует дополнительного флага возможностей клиента.
Чтобы подвести итог: