Thanks
Yes, there is a minor trigger on it, but that just populates the lastupdated date and DB host name fields, which will use the same values, irrespective of the user and application host PC. There are also the standard merge replication triggers on it, but they'd also have the same result irrespective of user. I'd kind of expect a different error if the issue was on replication metadata tables. And the error to repeat if run manually.
Further into: Note that the DB connection itself is just a shared SQL user, not a trusted connection. Initially I was thinking some sort of MDAC corruption, but if that was the case I was expecting the query in profiler to be corrupt. We do have the ability for trusted connections, but the clients don't generally use it as it means they have to manage the SQL rights for all the appropriate AD users on all the SQL hosts.
We have the software in several hundred machines, in around 100 different client environments and to date it has affected just 4 user accounts on 4 user machines in 4 different client environments. so pretty sparse.
Did you notice any difference in the connection settings (e.g. SET ANSI_NULLS etc.?) when you traced the problem?
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);mister.magoo (1/8/2014)
Did you notice any difference in the connection settings (e.g. SET ANSI_NULLS etc.?) when you traced the problem?
Good idea. I'll check once I can get access to the client machine (seems to have gone into hibernation). The Audit Login event in profiler should show that.
That said, I'm not expecting anything different, given same PC, same app, same application DB connection string.
EDIT: No, they are all the same.
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
I would concur with MM it could be the trigger.
Can you post the full code for the trigger?
Depending on what the trigger does, running the code in query window may not be the same as from the app!
Far away is close at hand in the images of elsewhere.
Anon.
I'm hitting this same problem using Management Studio.
In my case the SQL is trying to add new records for reference numbers which don't already exist in the target table (I've done a left join and filter for the reference on the target table being null).
Starting with an empty table I get an error (it should add around 75,000 rows).
If I add a TOP 10000 to the select and run it 8 times all 75,000 rows are added with no error.
If it was a genuine error one of those 8 runs would have failed when it hit the over length data.
Any ideas?
Viewing 10 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply