Showing posts with label call. Show all posts
Showing posts with label call. Show all posts

Friday, March 30, 2012

Problem with SQLBindParameter

I am developing an application, using ODBC, that needs to call a stored procedure in an SQL Server DBMS that has a mix of INPUT and INPUT_OUTPUT parameters. I have the code so that there aren't any errors returned from the function calls but I do not see the bound data change after the SQLExecute() function.

Code snippets follow.

CHAR szStatement[256];

CHAR szBuf[256];

SQLINTEGER irval = 0, filenum = 808042, DoNotCall = 0;
SQLVARCHAR vcPhoneNumber[PHONE_LEN];
SQLVARCHAR vcInstanceCode[INSTANCE_LEN] = {0x20};
SQLVARCHAR vcReason[REASON_LEN] = {0x20};
SQLINTEGER rvalLen = 0, fileLen = 0, noCallLen = 10, phoneLen = SQL_NTS, instanceLen = SQL_NTS, reasonLen = SQL_NTS;

lstrcpy( szStatement, "exec ?= some_proc ?, ?, ?, ?, ?" );

sqlr = SQLPrepare( hStmt, szStatement, lstrlen( szStatement ) );
sqlr = SQLBindParameter( hStmt, 1, SQL_PARAM_OUTPUT, SQL_C_LONG, SQL_INTEGER, 10, 0, &irval, 0, &rvalLen );
sqlr = SQLBindParameter( hStmt, 2, SQL_PARAM_INPUT, SQL_C_LONG, SQL_INTEGER, 10, 0, &filenum, 0, &fileLen );
sqlr = SQLBindParameter( hStmt, 3, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_CHAR, 10, 0, vcPhoneNumber, 10, &phoneLen );
sqlr = SQLBindParameter( hStmt, 4, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_VARCHAR, 50, 0, vcInstanceCode, 0, &instanceLen );
sqlr = SQLBindParameter( hStmt, 5, SQL_PARAM_INPUT_OUTPUT, SQL_C_LONG, SQL_INTEGER, 1, 0, &DoNotCall, 0, &noCallLen );
sqlr = SQLBindParameter( hStmt, 6, SQL_PARAM_INPUT_OUTPUT, SQL_C_CHAR, SQL_VARCHAR, 250, 0, vcReason, 0, &reasonLen );
sqlr = SQLExecute( hStmt );
if( sqlr == SQL_SUCCESS || sqlr == SQL_SUCCESS_WITH_INFO )

{
sprintf( szBuf, "The return value is %d", irval );
sprintf( szBuf, "The file number is %d", filenum );
sprintf( szBuf, "The phone number is %s", vcPhoneNumber );
sprintf( szBuf, "The instance code is %s", vcInstanceCode );
sprintf( szBuf, "The do not call value is %d", DoNotCall );
sprintf( szBuf, "The reason is %s", vcReason );
}

The problem is that in each of the function calls, the sqlr == SQL_SUCCESS but after the call to SQLExecute(), the data does not change for the output parameters. I can do something similar in other query tools that show the proper values but I am not getting the chanes in my bound variables. I tried adding a call to SQLParamData() but I was having a "Function sequence error" problem.

Any help would be very much appreciated. Thanks in advance.

Hi,

Here're a couple of ideas:

== The behavior of the output parameter may vary based on the actual stored proc, which you are trying to execute. To make sure your parameter description is precise, try using SQLProcedureColumns and examine the types.

== As per MSDN:

If the InputOutputType argument is SQL_PARAM_INPUT_OUTPUT or SQL_PARAM_OUTPUT, ParameterValuePtr points to a buffer in which the driver returns the output value. If the procedure returns one or more result sets, the *ParameterValuePtr buffer is not guaranteed to be set until all result sets/row counts have been processed. If the buffer is not set until processing is complete, the output parameters and return values are unavailable until SQLMoreResults returns SQL_NO_DATA. Calling SQLCloseCursor or SQLFreeStmt with an Option of SQL_CLOSE will cause these values to be discarded.

So what you could do is to fetch the results, call SQLMoreResults appropriately and see if the output parameter will be produced as expected. Also - don't forget the "SET NOCOUNT ON", you might get count tokens as separate resultsets.

HTH,

Jivko Dobrev - MSFT
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

At first I was having a problem with syntax errors and some other things that didn't make sense to me. I did some poking around and found that the signature I was given whas different from the signature that was defined in the data. I corrected this and was able to remove the errors. I tried calling SQLFetch() and was receiving an error of "Function sequense error." I can try again. The stored procedure does not return a result set. The return to me is throug a return code, the first parameter, and two in/out parameters, the last two.

I am connecting to someone else's system and they have defined the stored procedure and I don't have any control over how they've defined it.

The SQLExecute is returning SQL_SUCCESS_WITH_INFO and this message. The state is "01000" the native error is "0 The message is: [Microsoft][ODBC SQL Server Driver][SQL Server] The 01000 state is a generic message and that message sure looks generic. :)

I added a call to SQLFetch() after the SQLExecute() and the this is the result. The state is "HY010" the native error is "0 The message is: [Microsoft][ODBC SQL Server Driver]Function sequence error

I'm at a loss as to where to go now.

|||

Hi,

Would you be able to script the stored proc and the related tables/objects and post the script here? If it's not confidential or overly complicated, of course.

I have a suspicion about what you mentioned regarding the procedure not returning any rows. BTW - did you try the SQLMoreResults? Maybe you have multiple resultsets?

Thanks,

Jivko Dobrev - MSFT
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

The stored procedure does not return a result set. I don't think SQLMoreResults() would help.

The body, from a snippet I've been given looks something like this:

/*IsOKToCall Procedure*/
CREATE PROCEDURE IsOKToCall
@.FileNumber int,
@.PhoneNumber char(10),
@.Instance varchar(50),
@.DoNotCall int OUTPUT,
@.DoNotCallReason varchar(255) OUTPUT
AS

SELECT @.Instance = ISNULL(@.Instance, 'master')

-- TODO implement this method to return a non-zero in @.DoNotCall if the account should not be contacted.

SELECT @.DoNotCall = 0
SELECT @.DoNotCallReason = ''
Return @.@.Error

GO

Note that this is not the actual procedure. The person that created it has some PRINT statements in the body to show some debug values and there is logic to return different results based on the value passed in the FileNumber parameter. If I change the first parameter to SQL_PARAMETER_RETURN, I get an error when trying to bind the column. The live procedure also defines the OUTPUT parameters as INPUT_OUTPUT.

|||

An update:

I installed SQL Express so I can see what is going on with both sides of the issue. Some of the error message I thought I had were messages from the "print ......" statements the developers put in thier stored procedures. If I call SQLFetch() after the statement execution, I always have an error of "Function Sequense Error" so I don't think that is why I am not getting values back.

Isn't SQLBindParameter() supposed to bind the parameter in the driver so that when the values are returned, they are also changed in the bound parameters? Is there something else I must do to the the correct values?

|||

Someone explain this one to me. The statement being called is "exec ?= IsOkToCall ?, ?, ?, ?, ?" as far and myself and the driver are concerned, there are six parameters. The first one is bound to an INTEGER to receive the @.@.Error value. the second is the ID to search for and is an input type. The third one is a char type and an input parameter. The fourth is a varchar input type. The fifth is an integer and is input_output type to get a result value for logic. And the sixth is a varchar input_output used to recieve the message string. After getting all of the messages from the driver, the sixth parameter is being updated with the value that was set for the fifth result code variable. Changing the parameter numbers to see if there is an off by one error does not fix it.

What should I be looking for for this issue?

|||

Robert,

Do not change the parameter numbers but you should try to call SQLMoreResults until you hit SQL_NO_DATA_FOUND and then see if the output parameters are updated or not. I believe print statements are treated as results and thus have to be flushed before getting to output parameters.

Thanks

Waseem

|||I found that out the hard way. It is after gathering all of the data that I am seeing the mixed up returns. The first parameter that is the return value from the procedure is never set and I still have the wrong value being updated with the integer value and it does not change even after I remove all of the print statements from the stored procedure.|||

Waseem Basheer - MSFT wrote:

Robert,

Do not change the parameter numbers but you should try to call SQLMoreResults until you hit SQL_NO_DATA_FOUND and then see if the output parameters are updated or not. I believe print statements are treated as results and thus have to be flushed before getting to output parameters.

Thanks

Waseem

I found this to be the case and was doing so. I also found where I was setting the destination to the address of a pointer to a character array rather than sending the pointer to the character array. I also found this whole thing to be increadably finicky and full of poorly/non documented quirks. I have the IN/OUT parmeters working but the return code fom a call of "exec ?= my_proc ?, ?, ?" still illudes me. I am still not getting the value for the ?= parameter but I don't think It is too important for me to get this value.

Monday, March 26, 2012

Problem with SQL Query Analyzer

Hi,
I have the following problem: if I call a stored procedure from a program (via COM+/OLE DB) I measure the response time and I get something around 400 ms (including reading the data from the result set, a couple of MoveNext operations).
Now if I call the very same stored procedure within the SQL Query Analyzer, it takes almost 8 seconds until I can see the results! Does anybody know why?
Is the Query Analyzer so badly implemented when it reads the results and displays them?
Even if I eliminate the results (by adding select top 0 in my final query in the stored procedure) it still takes about 7 seconds within the Query Analyzer.
My bigger problem is that I use the query analyzer to fine-tune my application and it seems I can't rely on the results, because the same queries run differently once they are called from the application.
It's weird because I also get these confusing response times displayed in the Profiler! At the beginning I thought that the Query Analyzer adds some overhead, but why do I get different times in the Profiler?
Any hints/tips? Did anyone experience that before?
Thanks in advance,
Florin Micle
Execution plans can differ for several reasons. Different SET option is one potential reason. The first thing
to do is to compare the execution plans and see if they are the same or not.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"fmicle" <fmicle@.hotmail.com> wrote in message news:824E53F3-AC7C-4C1C-AFD5-06D4609F8714@.microsoft.com...
> Hi,
> I have the following problem: if I call a stored procedure from a program (via COM+/OLE DB) I measure the
response time and I get something around 400 ms (including reading the data from the result set, a couple of
MoveNext operations).
> Now if I call the very same stored procedure within the SQL Query Analyzer, it takes almost 8 seconds until
I can see the results! Does anybody know why?
> Is the Query Analyzer so badly implemented when it reads the results and displays them?
> Even if I eliminate the results (by adding select top 0 in my final query in the stored procedure) it still
takes about 7 seconds within the Query Analyzer.
> My bigger problem is that I use the query analyzer to fine-tune my application and it seems I can't rely on
the results, because the same queries run differently once they are called from the application.
> It's weird because I also get these confusing response times displayed in the Profiler! At the beginning I
thought that the Query Analyzer adds some overhead, but why do I get different times in the Profiler?
> Any hints/tips? Did anyone experience that before?
> Thanks in advance,
> Florin Micle
|||Perhaps your data happened to be cached in some instances. Try clearing the
cache using DBCC DROPCLEANBUFFERS before testing the queries using.
As Tibor mentioned, different execution plans may be another cause, which
you can also capture using Profiler.
Regards
Ray Mond
"fmicle" <fmicle@.hotmail.com> wrote in message
news:824E53F3-AC7C-4C1C-AFD5-06D4609F8714@.microsoft.com...
> Hi,
> I have the following problem: if I call a stored procedure from a program
(via COM+/OLE DB) I measure the response time and I get something around 400
ms (including reading the data from the result set, a couple of MoveNext
operations).
> Now if I call the very same stored procedure within the SQL Query
Analyzer, it takes almost 8 seconds until I can see the results! Does
anybody know why?
> Is the Query Analyzer so badly implemented when it reads the results and
displays them?
> Even if I eliminate the results (by adding select top 0 in my final query
in the stored procedure) it still takes about 7 seconds within the Query
Analyzer.
> My bigger problem is that I use the query analyzer to fine-tune my
application and it seems I can't rely on the results, because the same
queries run differently once they are called from the application.
> It's weird because I also get these confusing response times displayed in
the Profiler! At the beginning I thought that the Query Analyzer adds some
overhead, but why do I get different times in the Profiler?
> Any hints/tips? Did anyone experience that before?
> Thanks in advance,
> Florin Micle
|||Hi, when you look at profiler do you to capture exactly what it being run when the program calls the sp? I ask because unless the inputs are exactly the same you could get differing results. I've seen this with datetime inputs where query plans have been
different depending on the format of the date input. As Tibor says, did the query plan show anything different? I assume they must have done? You've tried the TOP 0 which should eliminate the displaying of the results and as Ray says you can drop the data
from cache (and run CHECKPOINT) to give the two approaches a level playing field. I feel the answer will be in your execution plan and I'd expect either as Tibor says, your SET options will be the root, or that it's perhaps something to do with one or mo
re of your sp inputs.
Alicia
Http://www.sqlporn.co.uk
|||Well, how am I suppose to know how exactly the query is executed and which query plan is taken?
I can see in the Profiler, that the exact same query is launched when I call it from my application and when I call it from the Query Analyzer. The query plan I can only see in the Query Analyzer, if I run my query in it, so I'll never know what plan is a
ctually taken when my query runs from the application.
That's exactly my problem, I can't tune my application properly, since the queries work differently in the Query Analyzer and from my app.
By the way, to answer your questions, the plan is always the same for my query.
I also think there are some bugs in the Profiler.
My stored procedure, let's name it SP1 calls 2 other SP's, which are very fast, let's call them SP2 and SP3.
So SP1 looks something like:
...
EXEC SP2
EXEC SP3
Do some complex queries
...
In the profiler, every time I call SP1, I get 3 SP Completed events, like this (two consecutive calls, you can see the effects of the cache, which is ok):
EventClass TextData Duration
SP:Completedexec SP1 0
SP:Completedexec SP1 0
SP:Completedexec SP1 453
SP:Completedexec SP1 0
SP:Completedexec SP1 0
SP:Completedexec SP1 313
Now, I call the same SP two times from the Query Analyzer, this is what I get in the profiler:
EventClass TextData Duration
SP:Completedexec SP2 0
SP:Completedexec SP3 0
SP:Completedexec SP1 1926
SP:Completedexec SP2 0
SP:Completedexec SP3 0
SP:Completedexec SP1 2005
The profiling mechanisms seem to be different, if the SP1 is called from the Query Analyzer it looks OK, but from my app, there seems to be a bug somwhere in the event handling in the Profiler.
Any ideas?
|||I can't believe this, if I delete the proccache (dbcc freeproccache) I get almost the same response times within QA like from my application!
About 600 ms, which is much better than 2 seconds!
What can make QA generate such a bad query plan?
Another thing: my application (C++) runs as a COM object in COM+. I wrote a small C++ program which does the exact same thing (calls the same stored procedure) and this is slower than when it runs in COM+. I use ATL OLE DB to connect to the DB in both cas
es.
I can only imagine, that there must be some magic in COM+, which sets some parameters differently, thus making the SQL Server run faster/better when called from COM+.
Confusing...
|||> What can make QA generate such a bad query plan?
The cached plan may have been generated for a query that uses parameter
values that do not fall into the same distribution pattern that the later
query has. However, this is unlikely in your case since you mentioned that
they are both using the same query.
I suggest checking the execution plan from both sides. Use Profiler to
capture the execution plan, using the Show Plan Statistics event under the
Performance heading.
Regards
Ray Mond
"fmicle" <fmicle@.hotmail.com> wrote in message
news:D42860F2-6C23-48C0-AA90-9301F2697191@.microsoft.com...
> I can't believe this, if I delete the proccache (dbcc freeproccache) I get
almost the same response times within QA like from my application!
> About 600 ms, which is much better than 2 seconds!
> What can make QA generate such a bad query plan?
> Another thing: my application (C++) runs as a COM object in COM+. I wrote
a small C++ program which does the exact same thing (calls the same stored
procedure) and this is slower than when it runs in COM+. I use ATL OLE DB to
connect to the DB in both cases.
> I can only imagine, that there must be some magic in COM+, which sets some
parameters differently, thus making the SQL Server run faster/better when
called from COM+.
> Confusing...
|||No, you're right, it makes sense. When I call the SP from COM+, I use placeholders and Accessors to bind my parameters.
But I get the exact same query text in the profiler.
On the other hand, if I do the same thing outside COM+, even using the parameters, I still get the bad plan (WITH PREFETCH).
I can only reach almost the same speed outside COM+ if I delete the PROCCACHE.

Tuesday, March 20, 2012

Problem with Searching unicode strings

Hi,
I have problem with Contains command . I've made index on FName column of my
database which is nvarchar(100).
When I call contains command to search for english strings , it works very
well .But when I search for unicode strings ( I use farsi strings and insert
them in unicode ), sometimes it can not find them , in more than 70 percent
unicode searches , it works correctly , but sometimes it can't find very
simple strings, for example : it can't find " ^??? " strings . I use
these commands to find :
Select * from MyDB where Contains(FName, N' ^??? ' )
or
Select * from MyDB where Contains(FName, ' ^??? ' )
but no one can find the string.
please tell me what is wrong in command or what can I do to solve this
problem.
In addition , I want to send result of Select @.@.version command for you .
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows
NT 5.0 (Build 2195: Service Pack 4)
Thanks in Advance
Hamid.
what collation are you using? This works for me.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Hamid" <hamid@.omid.ca> wrote in message
news:OcaRgT9IFHA.904@.tk2msftngp13.phx.gbl...
> Hi,
> I have problem with Contains command . I've made index on FName column of
my
> database which is nvarchar(100).
> When I call contains command to search for english strings , it works very
> well .But when I search for unicode strings ( I use farsi strings and
insert
> them in unicode ), sometimes it can not find them , in more than 70
percent
> unicode searches , it works correctly , but sometimes it can't find very
> simple strings, for example : it can't find " ^??? " strings . I use
> these commands to find :
> Select * from MyDB where Contains(FName, N' ^??? ' )
> or
> Select * from MyDB where Contains(FName, ' ^??? ' )
> but no one can find the string.
> please tell me what is wrong in command or what can I do to solve this
> problem.
> In addition , I want to send result of Select @.@.version command for you
..
> Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
> Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on
Windows
> NT 5.0 (Build 2195: Service Pack 4)
> ----
> Thanks in Advance
> Hamid.
>
>
|||Hi,
These documents could not help me.
I've used SQL_Latin1_General_CP1_CI_AS collation in database. As I told, all
English strings will find by use of contains where-clause , My problem is
with Unicode stringe , which it can not find them . It find about 70 percent
of strings and it ignores some strings in search.
Please tell me how can I solve this problem.
Any Comments or suggestions appreciated.
Hamid.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:u2ZyToEJFHA.2356@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> what collation are you using? This works for me.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Hamid" <hamid@.omid.ca> wrote in message
> news:OcaRgT9IFHA.904@.tk2msftngp13.phx.gbl...
of[vbcol=seagreen]
> my
very[vbcol=seagreen]
> insert
> percent
you
> .
> Windows
> ----
>

Problem with Search Unicode Strings by use of <Contains>

Hi,
I have problem with Contains command . I've made index on FName column of my
database which is nvarchar(100).
When I call contains command to search for english strings , it works very
well .But when I search for unicode strings ( I use farsi strings and insert
them in unicode ), sometimes it can not find them , in more than 70 percent
unicode searches , it works correctly , but sometimes it can't find very
simple strings, for example : it can't find " ^??? " strings . I use
these commands to find :
Select * from MyDB where Contains(FName, N' ^??? ' )
or
Select * from MyDB where Contains(FName, ' ^??? ' )
but no one can find the string.
please tell me what is wrong in command or what can I do to solve this
problem.
In addition , I want to send result of Select @.@.version command for you .
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows
NT 5.0 (Build 2195: Service Pack 4)
Also the Collation of Database and FName-field is :
SQL_Latin1_General_CP1_CI_AS
Thanks in Advance
Hamid.
Hamid,
First of all, thank you for providing the @.@.version (SQL Server 2000 SP3 on
Windows 2000 Server SP4) information along with the language (Farsi -
Iranian / Persian) and an example of your CONTAINS queries as this is most
helpful in helping you solve this problem!
Unfortunately, Farsi is not one of the subset of SQL Server 2000 supported
languages that Full Text Search supports, see SQL Server 2000 Books Online
title "Column-Level Linguistic Analysis", Note that it states that you
should "Use neutral when a column contains data in multiple languages or in
an unsupported language". Most likely, you have the FName column's "Language
for Word Breaker" set to US English. Could you confirm this with your reply
via sp_help_fulltext_columns ?
Assuming that you have your FT-enable column (FName) "Language for Word
Breaker" set to US English, you should drop the FT Catalog and re-create it
with the "Language for Word Breaker" set to Neutral and then run a Full
Population and re-test your CONTAINS query.
Additionally, you might want to checkout the new "Microsoft Arabic
Word-Breaker (Arabic Search Engine) - Beta" at
http://www.microsoft.com/middleeast/...v/beta/search/ and download the
Installation Guide and the Microsoft Arabic Word-Breaker. Now, I am not a
linguist, and I do not know how close or far apart Farsi or Persian is from
Arabic, but I'd suggest that you test it and let this newsgroup know if you
find it effective in resolving your FTS issues with Farsi strings.
Hope that helps!
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"Hamid" <hamid@.omid.ca> wrote in message
news:e5Z4#hsJFHA.3928@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have problem with Contains command . I've made index on FName column of
my
> database which is nvarchar(100).
> When I call contains command to search for english strings , it works very
> well .But when I search for unicode strings ( I use farsi strings and
insert
> them in unicode ), sometimes it can not find them , in more than 70
percent
> unicode searches , it works correctly , but sometimes it can't find very
> simple strings, for example : it can't find " ^??? " strings . I use
> these commands to find :
> Select * from MyDB where Contains(FName, N' ^??? ' )
> or
> Select * from MyDB where Contains(FName, ' ^??? ' )
> but no one can find the string.
> please tell me what is wrong in command or what can I do to solve this
> problem.
> In addition , I want to send result of Select @.@.version command for you
..
> Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
> Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on
Windows
> NT 5.0 (Build 2195: Service Pack 4)
> ----
> Also the Collation of Database and FName-field is :
> SQL_Latin1_General_CP1_CI_AS
> Thanks in Advance
> Hamid.
>
>

Friday, March 9, 2012

Problem with replication

Hi
Using SQL 7.0
I get this error :
>> Line 81: Incorrect syntax near '@.c1'.
when this SP is running :
{call sp_addsynctriggers (N'CstAdr', N'null', N'SRV-ERP',
N'OlympicProd', N'transwu1', N'sp_MSsync_ins_CstAdr_31',
N'sp_MSsync_upd_CstAdr_31', N'sp_MSsync_del_CstAdr_31',
N'dbo', N'null', N'ReplicRowVersion', N'null', 0x010000)}
Does anyone have an idea ?
Where is @.c1 ? What is in it ?
Thanks !
DonTry checking out the stored proc 'sp_addsynctriggers ' for '@.c1' (which is a
variable) and see what is going on in that area. One note, when SQL says
that an error is 'near' something, it means exactly that; somewhere in the
area of whatever it references (in this case '@.c1') it objects to something.
"Don" wrote:
> Hi
> Using SQL 7.0
> I get this error :
> >> Line 81: Incorrect syntax near '@.c1'.
> when this SP is running :
> {call sp_addsynctriggers (N'CstAdr', N'null', N'SRV-ERP',
> N'OlympicProd', N'transwu1', N'sp_MSsync_ins_CstAdr_31',
> N'sp_MSsync_upd_CstAdr_31', N'sp_MSsync_del_CstAdr_31',
> N'dbo', N'null', N'ReplicRowVersion', N'null', 0x010000)}
> Does anyone have an idea ?
> Where is @.c1 ? What is in it ?
> Thanks !
> Don
>

Wednesday, March 7, 2012

Problem with reading in packet mode

Hi Ovidiu,
First of all, I would like to confirm my understanding of your issue. From
your description, I understand that when you call SQLSetStmtOption() before
SQLExecDirect() the performance is quite poor. If there is any
misunderstanding, please feel free to let me know.
Yes, as you know, the SQLSetStmtOption can be called before/after
SQLExecDirect. However, from ODBC 3.x SQLSetStmtOption is deprecated. It
has been replaced by SQLSetStmtAttr. So I suggest you try to use
SQLSetStmtAttr to see if performance goes better. Please check the
following link for more information.
http://msdn.microsoft.com/library/d...-us/odbc/htm/od
bcsqlsetstmtoption.asp
If that still doens't work, please feel free to reply to the post.
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."Hi Ovidiu,
What is the version of MDAC on your machine? Please try to upgrade to the
latest version MDAC 2.8 sp1 from the following link to see if it can
resolved the problem.
http://www.microsoft.com/downloads/...c895-efc2-4f8e-
a9e0-3a1afbd5922e&DisplayLang=en
Also I suggest you try to set to a larger packet size (e.g. 512).
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."|||Hi Kevin,
Yes, I have the latest MDAC version: MDAC 2.8 SP1 on Windows XP SP2.
It's true, the performance gets much better when we increase the packet size
(we already knew that), as follows:
- for packet size 512 I get aprox. 7 secs (compared to 49 secs)
- increasing packet size over 512 won't improve performance anymore
The bottom line is: even when using larger values for the packet size,
performance is still poor compared
to the case when SQLSetStmtOption is called after SQLExecDirect (7 secs vs.
1 sec). Why is that happening ?
So, increasing packet size is a good workaround but up to a point.
There is the following bussiness impact: the customers using our application
are asking questions about this (strange) behaviour. Is there any
Microsoft doc, release note, etc. that refers to it ?
Could this issue be escalated such that, at least, we could get an official
answer from Microsoft regarding this behaviour. This would prove at
least that we are not misusing the ODBC API in any way (this was our main
concern in the first place because, actually, the order of ODBC
calls causes this strange behaviour).
Your help is appreciated.
Regards,
Ovidiu
"Kevin Yu [MSFT]" <v-kevy@.online.microsoft.com> wrote in message
news:hYsGn42hFHA.944@.TK2MSFTNGXA01.phx.gbl...
> Hi Ovidiu,
> What is the version of MDAC on your machine? Please try to upgrade to the
> latest version MDAC 2.8 sp1 from the following link to see if it can
> resolved the problem.
> [url]http://www.microsoft.com/downloads/details.aspx?FamilyID=78cac895-efc2-4f8e-[/ur
l]
> a9e0-3a1afbd5922e&DisplayLang=en
> Also I suggest you try to set to a larger packet size (e.g. 512).
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>|||Hi Ovidiu,
Here, I suggest you try to use 4096 as the packet size to see if there is
any performance increment.. To get an official answer from Microsoft, you
need to contact PSS for professional support. You can find the contact
information from the following link:
http://support.microsoft.com/common...=gp;en-us;offer
prophone
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."|||Hi Kevin,
As I already specified in my previous reply, increasing packet size over a
certain limit won't improve performance anymore.
Thanks for your help. I will try to escalate this issue through PSS.
Regards,
Ovidiu
"Kevin Yu [MSFT]" <v-kevy@.online.microsoft.com> wrote in message
news:clVPgQDiFHA.3120@.TK2MSFTNGXA01.phx.gbl...
> Hi Ovidiu,
> Here, I suggest you try to use 4096 as the packet size to see if there is
> any performance increment.. To get an official answer from Microsoft, you
> need to contact PSS for professional support. You can find the contact
> information from the following link:
> [url]http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer[/ur
l]
> prophone
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>|||Hi Ovidiu,
Sorry that I could not provide further assistance on this issue. Good luck!
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

Saturday, February 25, 2012

Problem with procedure call style

I try to execute code:
...
CallableStatement prep = conn.prepareCall("{call sp_xml_preparedocument
(?, ?)}");
prep.registerOutParameter(1, java.sql.Types.INTEGER);
prep.setString(2, "<root/>");
prep.executeUpdate();
System.out.println(prep.getInt(1));
CallableStatement rem = conn.prepareCall("{call sp_xml_removedocument
(?)}");
rem.setInt(1, prep.getInt(1));
rem.executeUpdate();
...
Java prints Exception Could not find prepared statement with handle 1.
Possible this problem is in using sp_execsql by MSSQL JDBC Driver.
How can I fix it?
Thank You!
| From: "Yuri Shustrov" <yuri_shustrov@.mail.ru>
| Subject: Problem with procedure call style
| Date: Fri, 10 Dec 2004 16:03:46 +0300
| Lines: 19
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
| Message-ID: <OBfhHir3EHA.2404@.TK2MSFTNGP14.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.jdbcdriver
| NNTP-Posting-Host: ns.escort-center.ru 212.176.17.195
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP14
.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6541
| X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
|
| I try to execute code:
| ...
| CallableStatement prep = conn.prepareCall("{call
sp_xml_preparedocument
| (?, ?)}");
| prep.registerOutParameter(1, java.sql.Types.INTEGER);
| prep.setString(2, "<root/>");
| prep.executeUpdate();
| System.out.println(prep.getInt(1));
| CallableStatement rem = conn.prepareCall("{call sp_xml_removedocument
| (?)}");
| rem.setInt(1, prep.getInt(1));
| rem.executeUpdate();
| ...
| Java prints Exception Could not find prepared statement with handle 1.
| Possible this problem is in using sp_execsql by MSSQL JDBC Driver.
| How can I fix it?
| Thank You!
|
|
|
Hello Yuri,
The SQL Server 2000 Books Online topic "sp_xml_preparedocument" states the
following:
"sp_xml_preparedocument returns a handle that can be used to access the
newly created internal representation of the XML document. This handle is
valid for the duration of the connection to Microsoft SQL Server 2000,
until the connection is reset, or until the handle is invalidated by
executing sp_xml_removedocument."
Your code shows two CallableStatements being prepared and executed on the
same connection variable "conn" without closing the first
CallableStatement. If you are using "SelectMethod=direct", then this will
result in a new cloned connection. Since the handle is only valid on the
first connection, the call to sp_xml_removedocument will fail. You can
resolve this by specifying "SelectMethod=cursor" in your connection string.
Otherwise, you can still use "SelectMethod=direct" and simply modify your
code so that the first CallableStatement is closed before the second
CallableStatement is prepared. This will maintain the same underlying
connection, and so the document handle will still be valid:
CallableStatement prep = conn.prepareCall("{call
sp_xml_preparedocument(?, ?)}");
prep.registerOutParameter(1, java.sql.Types.INTEGER);
prep.setString(2, "<root/>");
prep.executeUpdate();
System.out.println(prep.getInt(1));
int handle = prep.getInt(1);
prep.close();
prep = null;
CallableStatement rem = conn.prepareCall("{call
sp_xml_removedocument(?)}");
rem.setInt(1, handle);
rem.executeUpdate();
rem.close();
rem = null;
You can verify this behavior using SQL Profiler. In the failing scenario,
you will observe two different SPIDs (two different connections).
Hope that helps!
Carb Simien, MCSE MCDBA MCAD
Microsoft Developer Support - Web Data
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.