We’re running SQL 6.5 though ADO and we have the oddest problem.
This sentence will start generating deadlocks
insert clinical_notes ( NOTE_ID, CLIENT, MBR_ID, EPISODE, NOTE_DATE_TIME,
NOTE_TEXT, DEI, CARE_MGR, RELATED_EVT_ID, SERIES, EAP_CASE, TRIAGE, CATEGORY,
APPOINTMENT, PROVIDER_ID, PROVIDER_NAME )
VALUES ( 'NTPR3178042', 'HUMANA/PR', '999999999_001', 'EPPR915347',
'03-28-2011 11:25', 'We use á, é, í, ó, ú and ü (this is the least one we
use, but there''s a few words with it, like the city: Mayagüez).', 'APK', 'APK',
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL )
The trigger are the characters ú and ü. If they are in the NOTE_TEXT column.
NOTE_TEXT is a text column.
There are indexes on
UNC_not_id
NT_CT_MBR_NDX
NT_REL_EVT_NDX
NT_SERIES_NDX
idx_clinical_notes_date_time
nt_ep_idx
NOTE_ID is the primary key.
What happens is after we issue this statement, if we issue an identical one, but with a new NOTE_ID value, we receive the deadlock.
As mentioned, this only happens when ú or ü is in NOTE_TEXT.
This is a test server and there is generally only one session accessing this table when the error occurs.
I’m sure it has something to so with character sets and such, but for the life of me I can’t work it out.
Is the column (var)char-based or n(var)char-based? Are the values using unicode above 255 or are they ascii 255 or below (250 and 252)?
Try changing the column to a binary collation, just to see if that helps (it may shed light on the issue). I do NOT know if this works in SQL 2000 (though I can check on Monday), but you can try this to find what collations are available on your server:
Latin General BIN should be in there somewhere.
Assuming you find a collation to try, you change the collation like so:
Script out your table to learn the collation it’s using now so you can set it back if that doesn’t work or causes problems. Or use a backup. 🙂
One additional note is that if you’re using unicode you do need an N before literal strings, for example: