2

It is well-known that MS Access applications (MDBs) using SQL Server backends have trouble with certain data types. For example,

We are now considering to move from text/ntext fields to varchar(MAX)/nvarchar(MAX) fields, as recommended by Microsoft:

ntext, text, and image data types will be removed in a future version of Microsoft SQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.

Are we going to run into trouble doing that?

Andre
  • 26,751
  • 7
  • 36
  • 80
Heinzi
  • 167,459
  • 57
  • 363
  • 519

5 Answers5

2

I know this is an older post, but I think it is still relevant to some folks. I deal a lot with legacy data that is scaled up from Access Memo fields to SQL and then turned into a link table in Access.

I have found that scaling to NVARCHAR(max) does cause issue within the link tables. Depending on which driver you are building the Access Link table with, the problem varies.

Using SQL Native Client 10 my first finding is that Access treats the field as a NVARCHAR(4000). While using SQL Server as the driver does change the issues, there are still issues. With this older driver the issues seem to be harder to track down but do show up. Usually with a similar sizing problem.

Beware, what seems to be running ok, may in fact just be running correctly because the right circumstance has not been hit yet.

If you find that your field data never requires more than 4000 characters, then make it a NVARCHAR(4000). To set at MAX is over kill if you only need 4000 anyway.

JStevens
  • 2,090
  • 1
  • 22
  • 26
1

We definitely discovered a pitfall recently. The problem is that one couldn't write more than 8000 bytes to a varbinary field of a linked table, even if the field is defined as varbinary(MAX).

Proof: varbinary(MAX) on linked tables

Lee Taylor
  • 7,761
  • 16
  • 33
  • 49
1

This is an addendum to the answer by JStevens.

The newer ODBC drivers for SQL Server limit VARCHAR(MAX) to 8000 characters. Trying to enter more text via a linked ODBC table results in this ODBC error:

[Microsoft][ODBC Driver 17 for SQL Server]String data, right truncation (#0)

It works with the ancient {SQL Server} driver, or with data type TEXT.
And surprisingly, it also works with NVARCHAR(MAX) !

These findings are with Access 2010 or 2016, and SQL Server 2008 R2.

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

So you have to pick your poison if you need to insert more data.

{SQL Server} wasn't an option for me, e.g. because it doesn't support the DATE data type.

So I stick with TEXT and hope that "ntext, text, and image data types will be removed in a future version of SQL Server." is just an empty threat.

Necro edit: NVARCHAR(MAX) doesn't seem to have the 8000 (or 4000) character limit with the new ODBC drivers.

Andre
  • 26,751
  • 7
  • 36
  • 80
1

We are in the same situation: MS-Access front end, SQL Server back end. We are already creating all new fields as nvarchar(max) instead of ntext, without any problem on the user side. As we do not use either text or image field types, I cannot say anything on them.

Philippe Grondier
  • 10,900
  • 3
  • 33
  • 72
1

At work, we have the same setup as well (Access 2003 frontend, SQL Server 2005 backend) and we did exactly what you are asking about:

We had SQL Server tables with text/ntext columns, and we changed them to varchar(max)/nvarchar(max).
We didn't experience any problems at all, if I remember it correctly we didn't even have to re-link the tables in Access...it just worked.

Christian Specht
  • 35,843
  • 15
  • 128
  • 182