>>The ODBC driver is definitely truncating, but I don't know why... From SQL.LOG:
>>
>>
>>SWORD 1
>>PTR 0x01C31853 [ 31] "special, department, category\ 0\ 0"
>>SQLLEN 31
>>SQLLEN * 0x0012F4B0 (41)
>>
>>DIAG [01004] [Microsoft][ODBC SQL Server Driver]String data, right truncation (0)
>
>The problem is due to the long field that the SP creates to hold the information (nvarchar(2078). What you are actually getting back is the MOD() of that size and 256.
>
>To get what you want you have to do some of the processing yourself. try the following SQL statement, it should get you what you want:>lctable = "MyTable"
>sqlexec(lnconn,"select index_col(?lctable,sysindexes.indid,1) as 'PK' ;
> from sysindexes where sysindexes.id = <b>object_id(?lctable)</b> ;
> and (sysindexes.status & 2048) <> 0", 'csrIDX1')
>& is a bitwise & in T-SQL and 2048 is the status SQL Server uses to determine if an index is used to enforce the primary key constraint.
>
>The 1 used in the index_col() function is used to designate which key expression of the index you want return. IN this case, I am assuming that the key is on 1 field so you would use 1.
>
>HTH.
Correction in bold.
FWIW, the change you made to the SP could also have been done by changing the nvarchar(2078) field to a varchar(2078) field. If you had done this, VFP would have converted the field to a Memo and you could have parsed that. It is only the Unicode attribute of the field that VFP/ODBC had problems with.
Larry Miller
MCSD
LWMiller3@verizon.netAccumulate learning by study, understand what you learn by questioning. -- Mingjiao
