Переход от текста к varchar (MAX): Есть ли какие-либо проблемы с MS Access?

Question

Хорошо известно, что приложения MS Access (MDB), использующие бэкэнды SQL Server, имеют проблемы с определенными типами данных. Например,

• бит поддержка поля нарушена: значения NULL приводят к странным ошибкам ,
• десятичное поддержка поля нарушена: Сортировка не работает правильно ,
• и т.д.

Теперь мы рассматриваем возможность перехода от text / ntext полей к varchar (MAX) / nvarchar (MAX) полей, в соответствии с рекомендациями Microsoft :

Типы данных ntext, text и image будут удалены в следующей версии Microsoft SQL Server. Избегайте использования этих типов данных в новых разработках и планируйте модифицировать приложения, которые их используют в настоящее время. Используйте взамен nvarchar (max), varchar (max) и varbinary (max).

Мы собираемся столкнуться с проблемами при этом?

Answer 1

Я знаю, что это старый пост, но я думаю, что он по-прежнему актуален для некоторых людей. Я много работаю с устаревшими данными, которые масштабируются из полей Access Memo в SQL, а затем превращаются в таблицу ссылок в Access.

Я обнаружил, что масштабирование до NVARCHAR (max) вызывает проблемы в таблицах ссылок. Проблема зависит от того, с каким драйвером вы строите таблицу Access Link.

Используя SQL Native Client 10, я впервые обнаружил, что Access обрабатывает поле как NVARCHAR (4000). Хотя использование SQL Server в качестве драйвера действительно меняет проблемы, все еще существуют проблемы. С этим более старым драйвером проблемы, кажется, труднее отследить, но они обнаруживаются. Обычно с похожей проблемой размеров.

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

Если вы обнаружите, что ваши полевые данные никогда не требуют больше 4000 символов, то сделайте их NVARCHAR (4000). Установить на MAX - слишком много, если вам все равно нужно 4000.

Answer 2

Это дополнение к ответу от JStevens.

Новые драйверы ODBC для SQL Server ограничивают VARCHAR(MAX) до 8000 символов. Попытка ввести больше текста через связанную таблицу ODBC приводит к этой ошибке ODBC:

[Microsoft] [Драйвер ODBC 17 для SQL Server] Строковые данные, усечение справа (# 0)

Он работает с древним драйвером {SQL Server} или с типом данных TEXT.

Эти выводы относятся к Access 2010 или 2016 и SQL Server 2008 R2.

+--------------------+--------------+---------------------------------+
| Data type \ Driver | {SQL Server} | {ODBC Driver 17 for SQL Server} |
+--------------------+--------------+---------------------------------+
| VARCHAR(MAX)       | ok           | ODBC Error                      |
| TEXT               | ok           | ok                              |
+--------------------+--------------+---------------------------------+

Так что вам нужно выбрать яд, если вам нужно вставить больше данных.

{SQL Server} не подходит для меня, например, потому что он не поддерживает тип данных DATE.

Поэтому я придерживаюсь TEXT и надеюсь, что «типы данных ntext, text и image будут удалены в будущей версии SQL Server». это просто пустая угроза .

Answer 3

На работе у нас есть такая же настройка (внешний интерфейс Access 2003, серверная часть SQL Server 2005), и мы сделали именно то, о чем вы спрашиваете:

У нас были таблицы SQL Server с text / ntext столбцами, и мы изменили их на varchar(max) / nvarchar(max).
У нас вообще не было никаких проблем, если я правильно помню, нам даже не нужно было повторно связывать таблицы в Access ... это просто сработало.

Answer 4

Ну, мы определенно получили подводный камень недавно.Проблема в том, что невозможно записать более 8000 байтов в поле varbinary связанной таблицы, даже если это поле определено как varbinary (max).

Proof: varbinary (MAX) всвязанные таблицы

Answer 5

Мы находимся в такой же ситуации: внешний интерфейс MS-Access, внутренний сервер SQL Server. Мы уже создаем все новые поля как nvarchar (max) вместо ntext, без каких-либо проблем на стороне пользователя. Поскольку мы не используем текстовые или графические типы полей, я не могу ничего о них сказать.