I am working with Access frontends and a SQL Server 2000 backend.
One user gets the following error when trying to insert directly into
a table through access or through a form into that same table: "String
or binary data would be truncated". It doesn't matter into which type
of column the data is entered. Int, datetime, varchar all produce the
same error.
This user has access to the db this table is stored in and can write
to other tables in that db with no problem. In fact, none of the other
users with the same permission settings to this db has this problem.
They can insert into or update this same table just fine.
This is also pc independent for this user. It does seem to be a matter
of account setting though, because none of the other users has this
problem.
What could be wrong? Does anybody have any ideas? As far as I know
this user has the exact same permission setting as others. What else
could I look into to solve this mystery?
Thanks for your help.
> One user gets the following error when trying to insert directly into
> a table through access or through a form into that same table: "String
> or binary data would be truncated".
This sounds like a string is attempting to be inserted but it is too long to
fit in the column. This is not a "weird" error, in fact it is quite common.
I highly doubt it has anything to do with this user or his/her permissions,
unless there is a trigger on the table and the failure is occurring because
his domain username is too long to fit into the auditing table.
|||I fixed the problem. As it turned out, for this particular user the
username is saved with its domain name. The table field to which this
user info is saved wasn't large enough to hold both the username and
domain name.
Thanks for your reply, Aaron. As you predicted, the username was too
long to be stored.
On Mar 11, 9:33 am, "Aaron Bertrand [SQL Server MVP]"
<ten...@.dnartreb.noraa> wrote:
> This sounds like a string is attempting to be inserted but it is too long to
> fit in the column. This is not a "weird" error, in fact it is quite common.
> I highly doubt it has anything to do with this user or his/her permissions,
> unless there is a trigger on the table and the failure is occurring because
> his domain username is too long to fit into the auditing table.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment