By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,504 Members | 2,318 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,504 IT Pros & Developers. It's quick & easy.

Problems with Access XP and SQL Server

P: n/a
We have an access project linked to sql server on a windows 2000
network. Project is stored on a network share so all users access the
same version.

User A loads the project attempts to insert a record. Gets an error
8152 string or binary data will be truncated.

User B loads the project attempts to insert the *same* record -
success.

Delete user A, delete all related files, copy User B in active
directory.

Try User A again - same result. Have tried this on a range of machines
with the same result.

Copy another user from user B - no problems. Can insert records no
problem.

This has got me and my network manager totally banjaxed.

*Any* thoughts on what might be going wrong or what I can do to sort
this out?
Nov 12 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On 19 Dec 2003 01:24:57 -0800, ma*****@enorf.ac.uk (John McCabe) wrote:
We have an access project linked to sql server on a windows 2000
network. Project is stored on a network share so all users access the
same version.
Not a good idea - shared front-ends load slowly and are prone to corruption.
Should keep a central copy, but don't open it directly. Copy latest version
to each workstation, and open from there.
User A loads the project attempts to insert a record. Gets an error
8152 string or binary data will be truncated.

User B loads the project attempts to insert the *same* record -
success.


Same MDAC version? Same Office Service Pack?

Nov 12 '05 #2

P: n/a

I know that a central copy is silly. This is *purely* devlopment and was
to say that the code was definitely static between the users and was
being run from a common location.

Same office version. Same service pack. Same *machine*.

That's the headache. All users login to the *same* machine. All users
use the same code. Some work. Some don't. Can't see why.
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #3

P: n/a
That type of error is from SQL Server and is warning you that the data you
are trying to insert is too long for the field. You should either increase
the capacity of the field if you are allowed to do so.

From my view, it would seem that one user is typing less data and avoiding
the error.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
"John McCabe" <ma*****@enorf.ac.uk> wrote in message
news:3e**************************@posting.google.c om...
We have an access project linked to sql server on a windows 2000
network. Project is stored on a network share so all users access the
same version.

User A loads the project attempts to insert a record. Gets an error
8152 string or binary data will be truncated.

User B loads the project attempts to insert the *same* record -
success.

Delete user A, delete all related files, copy User B in active
directory.

Try User A again - same result. Have tried this on a range of machines
with the same result.

Copy another user from user B - no problems. Can insert records no
problem.

This has got me and my network manager totally banjaxed.

*Any* thoughts on what might be going wrong or what I can do to sort
this out?

Nov 12 '05 #4

P: n/a
It sounds like the users are entering different data, and you are inserting
from code using a SQL - INSERT command. The error is telling you that you're
trying to enter more data than a field will hold. This won't come up with
bound forms since Access will not let the user type more characters than a
field can contain.

On 19 Dec 2003 11:00:11 GMT, john mccabe <ma*****@enorf.ac.uk> wrote:

I know that a central copy is silly. This is *purely* devlopment and was
to say that the code was definitely static between the users and was
being run from a common location.

Same office version. Same service pack. Same *machine*.

That's the headache. All users login to the *same* machine. All users
use the same code. Some work. Some don't. Can't see why.
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!


Nov 12 '05 #5

P: n/a
"Jerry Boone" <je***@antech.biz.killspam> wrote in message news:<Dv*****************@newssvr23.news.prodigy.c om>...
That type of error is from SQL Server and is warning you that the data you
are trying to insert is too long for the field. You should either increase
the capacity of the field if you are allowed to do so.

From my view, it would seem that one user is typing less data and avoiding
the error.

Yup. We worked it out with the guy who developed the SQL side. It's
not the user's typing it's the auditing.

What was going wrong was that we were logging the userID and we only
got the error message for users with long login names 'cos we hadn't
allowed enough space for this.
Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.