Client-specific Insert Error?

I've got a C#/sql2005 program begun in C#2 and now using C#3 that is only misbehaving for one user. He IS able to use the program to select, insert, delete--even BACKUP--but he is NOT able to insert into ONE TABLE... He's running against a sqlexpress database on his own machine (just like all our other FUNCTIONING users)

He's in the field and is an admin on the machine <...I know...> so I have no idea what he might have installed or fiddled with before or after installing my program, AND I won't be able to get to his computer in time for hands-on platform-specific troubleshooting.

SO--in this instance--I'd love to be able to lay the blame on my code because I could just FIX it and send him an update, but the more I think about it, the more it seems like a configuration issue... or a corruption? (If it's a corruption, though, it wasn't evident when I restored his DB to my own sql2005 server and ran it with the sam开发者_如何学JAVAe program build he's using)

NEW INFORMATION

3/9/11 10:45 AM -5GMT

Remember I said that the program was originally dev'd on c#2 but now is running on c#3? Well, this user does NOT have the .NET 2.0 framework on his PC. He's got .NET 1.1+ and .NET 3.5. I realized this when he mentioned that he'd ALSO had trouble adding items to a Dictionary<string,object> He got this error:

Item cannot be added to a read-only or fixed-size list

Is it possible that both problems stem from the absence of the .NET 2.0 framework?

Again, any help will be appreciated.

Not much information to work with, such as the method of insert, transaction depth, error text, etc.. But can throw a few guesses out there.

Disk Space would be my first guess. The table is set to a finite expansion or on a volume that is simply out of space. All other methods(reading, deleting) would succeed, but expanding the table would fail. Especially if the filegroup is set to expand at a really large rate(%10+), if you've reached the size limitation and it attempts to expand the filegroup and runs out of space, the transaction will fail.

Ditto for the log file...

Next would be a permissions issue, which is not likely since he can delete and update.

Next would be an identity primary key that has indexed to it's upper-bounds. If you are using a tiny\small int or something and have hit the max on the range, you'd get a violation.

Just guesses with what is available.