Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 SRVBIGVARCHAR only gets first 255 characters

Author  Topic 

Parker
Starting Member

2 Posts

Posted - 2004-05-05 : 18:53:02
Hi there,

Can someone please help me? I have an extended stored procedure written in C++ .NET. SQL Server 2000 is calling this DLL from a stored procedure. Certain input parameters are VARCHAR(8000) type, and I have written my C++ code correctly so that the code identifies the parameters as type SRVBIGVARCHAR. It even recognizes that the max length is 8000. Further, it even correctly determines the length of the string I passed in! The only thing is does not do is get the whole string; the first 255 are passed ONLY. So when I am referencing my data, I get blanks or other characters beyond position 255. I am using the service pack 3a of sql 2000. Please help!

Eric

RickD
Slow But Sure Yak Herding Master

3608 Posts

Posted - 2004-05-06 : 05:10:17
Where are you looking to see that it only gets the first 255 characters??

If it is QA, then change the maximum charachters per column in the results tab of the tools options...
Go to Top of Page

Parker
Starting Member

2 Posts

Posted - 2004-05-07 : 12:25:08
No, I wrote an extended stored procedure DLL in C++. The relevant SQL for calling this is:
exec @ti=xp_e_DQFull_GetNextItem
@ti1,@ti2,@ti3,@ts4,@ts5,@ts6,@ts7,@ts8,@ts9,
@toutf1 output,@toutf2 output,@touti1 output

where @ts4 to @ts9 were declared as varchar(8000) variables.

The C++ code at the start of the DLL is:

RETCODE __declspec(dllexport) xp_e_DQFull_GetNextItem(SRV_PROC *srvproc)
{
/////////////////////////////////////////
// count parameters and check their types

char tsz[100];
double tf;
int i,j,k;
int iParamCount;
iParamCount=srv_rpcparams(srvproc);

if (iParamCount!=12)
return -10;
int iLength[12];
for (i = 1; i <= iParamCount; i++)
{
char szText[15] = "Hello World!";
BYTE *bType=new BYTE[1];
ULONG *cbMaxLen=new ULONG[1];
ULONG *cbActualLen=new ULONG[1];
BOOL fNull;

// Use srv_paraminfo to get data type and length information.
if (srv_paraminfo(srvproc, i, bType, cbMaxLen, cbActualLen,NULL, &fNull)== FAIL) return (-999);
iLength[i-1]=cbActualLen[0];

// Make sure the last 3 parameters are return (OUTPUT) parameters
if (i==10 || i==11 || i==12) {
if ((srv_paramstatus(srvproc, i) & SRV_PARAMRETURN) == FAIL) return (-998);
}

// Make sure parameters are correct datatypes
if (i<=3 && bType[0] != SRVINTN) return -31;
if (i>3 && i<10 && bType[0] != SRVBIGVARCHAR) return -32;
else if (i>3 && i<10 && cbMaxLen[0]!=8000) return -33;
if (i>=10 && i<=11 && bType[0] != SRVFLTN) return -34;
if (i==12 && bType[0] != SRVINTN) return -35;
}

Now cbMaxLen[0] does equal 8000, which is good. That says that the DLL thinks the maximum length of the string is 8000 characters, which it should be. Further, bType[0] equals SRVBIGVARCHAR, which puportedly has a max length of 8000, which is good. Finally, cbActualLen[0] equals the correct actual length of the string, e.g., 254, 255, 256, 5002, etc. BUT all data beyond position 255 is read as blanks. The parameters are pointers to the data in fact, so the code for "reading" the data is just:

int *piNumItems,*piMLEPercJump,*piMaxCN;
char *pszQIDList,*pszSPList,*pszLPList,*pszCNList,*pszCPList,*pszIAList;

piNumItems=(int*) srv_paramdata(srvproc,1);
piMaxCN=(int*) srv_paramdata(srvproc,2);
if (piNumItems[0]<1 || piMaxCN[0]<2) return -40;

piMLEPercJump=(int*) srv_paramdata(srvproc,3);
if (piMLEPercJump[0]<0 || piMLEPercJump[0]>100) return -50;

pszQIDList=(char*) srv_paramdata(srvproc,4);
pszSPList=(char*) srv_paramdata(srvproc,5);
pszLPList=(char*) srv_paramdata(srvproc,6);
pszCNList=(char*) srv_paramdata(srvproc,7);
pszCPList=(char*) srv_paramdata(srvproc,8);
pszIAList=(char*) srv_paramdata(srvproc,9);

And running through the data with these pointers yeilds 255 correct charcters (i.e., what was fed in is what I get here) followed by nothing but blanks. I suspect this is a bug in how SQL 2000 passes varchar(8000) data to extended stroed procedures, but I hope there is a simple workaround. Please help, anyone!

Eric
Go to Top of Page
   

- Advertisement -