OUTPUT - help with please

I am using a dynamic t-sql string in proc1 to execute proc2, which returns an int variable named @.Fatal_Error back to proc1.

When I execute proc2 I use the syntax:

EXEC @.SQL @.Params

@.SQL is the Proc Name (varchar) and @.Params is the parameter string (nvarchar).

If I include the @.Fatal_Error variable in the dynamic creation of the @.Params string the returning value from Proc2 is unable to convert int to nvarchar.

I have declared @.Fatal_Error in proc1 as int and tried to add to the end of my dynamic t-sql EXEC but I still get 'Cannot convert int to nvarchar' .

Please help - I'm beginning to pull out hair! :-)

Thanks!

Here' s the syntax I tried when just passing it at the end of the EXEC call:

EXEC @.SQL @.Param_List = @.Fatal_Error

AND I also tried:

EXEC @.SQL @.Param_List + ' '+@.Fatal_Error+' '

You have to use the sp_executesql for parameterized dynamic sql,

Code Snippet

Declare @.idParm as int;

Declare @.nameParm as varchar(100);

Declare @.dynamicSql as nvarchar(1000);

Declare @.dynamicParamDef as nvarchar(1000);

Set @.idParm = 2;

Set @.nameParm = 'sysobjects'

Set @.dynamicSql = N'Select * from sysobjects where id=@.id or name=@.name'

Set @.dynamicParamDef = N'@.id as int, @.name as varchar(100)'

Exec sp_executesql @.dynamicSql, @.dynamicParamDef, @.idParm, @.nameParm

|||

I quote from BOL(look for sp_executesql, building statement at runtime)

"

Transact-SQL supports the following methods of building SQL statements at run time in Transact-SQL scripts, stored procedures, and triggers:

Use the sp_executesql system stored procedure to execute a Unicode string. sp_executesql supports parameter substitution similar to the RAISERROR statement.

Use the EXECUTE statement to execute a character string. The EXECUTE statement does not support parameter substitution in the executed string."|||...and Manivannan prove it|||

Thank you all for your assistance. I will give it a whirl.

I was able to finally execute with EXEC @.SQL @.Params, @.Fatal_Error = @.Fatal_Error

However, I'm sure this will come back to bite me in the long run..

Thank you ALL for your quick replies!

|||

@.SQL is my stored procedure name

@.Param_List is the list of enumerated parameters

SET @.SQL = @.SQL + IsNull(@.Param_List,'');

EXECUTE sp_executesql @.SQL;

Worked like a charm.

Thanks!

Sandy

other characters (codes) that represent single quote

Hi,
I am trying to replace every single quote with two "single quotes", prior to
sending the dynamic sql string to sql server.
( from a C# application)
(in this case I have to send a dynamic string, cannot do parametarized
queries)
Question is....
Is there any other character that sql server will interpret as a "single
quote"?
Any help is deeply appreciated.
Thanks
NalakaHi Nalaka,
Thank you for your post.
Based on my scope, I don't think SQL Server will interpret other character
as single quote.
Here I would like provide some information about passing dynamic string to
SQL Server:
When possible, reject input that contains the following characters.
Input character Meaning in Transact-SQL
; Query delimiter
' Character data string delimiter
-- Comment delimiter
/* ... */ Comment delimiters. Text between /* and
*/ is not evaluated by the server.
Xp_ Begins the name of catalog extended stored
procedures such as xp_cmdshell.
You may need to refer the following article:
SQL Injection
http://msdn2.microsoft.com/en-us/library/ms161953.aspx
Hope this will be helpful!
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thanks Wei,
This is what I don't understand... theoretically if I replace every single
quote with two single quotes.. all is well.
But there is a ton of articles suggesting all these other precautions.....
Nalaka
"Wei Lu" <weilu@.online.microsoft.com> wrote in message
news:1Kfz6%23FhGHA.5608@.TK2MSFTNGXA01.phx.gbl...
> Hi Nalaka,
> Thank you for your post.
> Based on my scope, I don't think SQL Server will interpret other character
> as single quote.
> Here I would like provide some information about passing dynamic string to
> SQL Server:
> When possible, reject input that contains the following characters.
> Input character Meaning in Transact-SQL
> ; Query delimiter
> ' Character data string delimiter
> -- Comment delimiter
> /* ... */ Comment delimiters. Text between /* and
> */ is not evaluated by the server.
> Xp_ Begins the name of catalog extended
> stored
> procedures such as xp_cmdshell.
> You may need to refer the following article:
> SQL Injection
> http://msdn2.microsoft.com/en-us/library/ms161953.aspx
> Hope this will be helpful!
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>|||"Nalaka" <nalaka12@.nospam.nospam> wrote in message
news:%23CKpYJOhGHA.2188@.TK2MSFTNGP04.phx.gbl...
> Thanks Wei,
> This is what I don't understand... theoretically if I replace every single
> quote with two single quotes.. all is well.
> But there is a ton of articles suggesting all these other
precautions.....
>
Most likely their concern for SQL injection attacks.
Basically any place you accept input, if you're not careful, a bad user
could do something like:
Enter First Name: dummy; select * from sysobjects
And if your select query isn't written well, it now becomes something like:
Select id from table where fname=dummy; select * from sysobjects and now
your sysobjects table has been returned to the hacker.
> Nalaka
>
> "Wei Lu" <weilu@.online.microsoft.com> wrote in message
> news:1Kfz6%23FhGHA.5608@.TK2MSFTNGXA01.phx.gbl...
> > Hi Nalaka,
> >
> > Thank you for your post.
> >
> > Based on my scope, I don't think SQL Server will interpret other
character
> > as single quote.
> >
> > Here I would like provide some information about passing dynamic string
to
> > SQL Server:
> >
> > When possible, reject input that contains the following characters.
> >
> > Input character Meaning in Transact-SQL
> > ; Query delimiter
> >
> > ' Character data string delimiter
> >
> > -- Comment delimiter
> >
> > /* ... */ Comment delimiters. Text between /*
and
> > */ is not evaluated by the server.
> >
> > Xp_ Begins the name of catalog extended
> > stored
> > procedures such as xp_cmdshell.
> >
> > You may need to refer the following article:
> >
> > SQL Injection
> > http://msdn2.microsoft.com/en-us/library/ms161953.aspx
> >
> > Hope this will be helpful!
> >
> > Sincerely,
> >
> > Wei Lu
> > Microsoft Online Community Support
> >
> > ==================================================> >
> > When responding to posts, please "Reply to Group" via your newsreader so
> > that others may learn and benefit from your issue.
> >
> > ==================================================> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> >
>|||Hi Nalaka,
Thank you for the update.
As Greg mentioned, there is some secury issue you should considered in you
application code.
SQL injection should be avoid.
You could refer the article I posted in the previous post.
SQL Injection
http://msdn2.microsoft.com/en-us/library/ms161953.aspx
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thanks...
"Wei Lu" <weilu@.online.microsoft.com> wrote in message
news:ugdnCtVhGHA.5608@.TK2MSFTNGXA01.phx.gbl...
> Hi Nalaka,
> Thank you for the update.
> As Greg mentioned, there is some secury issue you should considered in you
> application code.
> SQL injection should be avoid.
> You could refer the article I posted in the previous post.
> SQL Injection
> http://msdn2.microsoft.com/en-us/library/ms161953.aspx
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>|||Hi Nalaka,
Glad to hear the information is helpful.
If you have any questions or concerns, please feel free to let me know.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.

other characters (codes) that represent single quote

Hi,
I am trying to replace every single quote with two "single quotes", prior to
sending the dynamic sql string to sql server.
( from a C# application)
(in this case I have to send a dynamic string, cannot do parametarized
queries)
Question is....
Is there any other character that sql server will interpret as a "single
quote"?
Any help is deeply appreciated.
Thanks
NalakaHi Nalaka,
Thank you for your post.
Based on my scope, I don't think SQL Server will interpret other character
as single quote.
Here I would like provide some information about passing dynamic string to
SQL Server:
When possible, reject input that contains the following characters.
Input character Meaning in Transact-SQL
; Query delimiter
' Character data string delimiter
-- Comment delimiter
/* ... */ Comment delimiters. Text between /* and
*/ is not evaluated by the server.
Xp_ Begins the name of catalog extended stored
procedures such as xp_cmdshell.
You may need to refer the following article:
SQL Injection
http://msdn2.microsoft.com/en-us/library/ms161953.aspx
Hope this will be helpful!
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.|||Thanks Wei,
This is what I don't understand... theoretically if I replace every single
quote with two single quotes.. all is well.
But there is a ton of articles suggesting all these other precautions.....
Nalaka
"Wei Lu" <weilu@.online.microsoft.com> wrote in message
news:1Kfz6%23FhGHA.5608@.TK2MSFTNGXA01.phx.gbl...
> Hi Nalaka,
> Thank you for your post.
> Based on my scope, I don't think SQL Server will interpret other character
> as single quote.
> Here I would like provide some information about passing dynamic string to
> SQL Server:
> When possible, reject input that contains the following characters.
> Input character Meaning in Transact-SQL
> ; Query delimiter
> ' Character data string delimiter
> -- Comment delimiter
> /* ... */ Comment delimiters. Text between /* and
> */ is not evaluated by the server.
> Xp_ Begins the name of catalog extended
> stored
> procedures such as xp_cmdshell.
> You may need to refer the following article:
> SQL Injection
> http://msdn2.microsoft.com/en-us/library/ms161953.aspx
> Hope this will be helpful!
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ========================================
==========
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ========================================
==========
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>|||"Nalaka" <nalaka12@.nospam.nospam> wrote in message
news:%23CKpYJOhGHA.2188@.TK2MSFTNGP04.phx.gbl...
> Thanks Wei,
> This is what I don't understand... theoretically if I replace every single
> quote with two single quotes.. all is well.
> But there is a ton of articles suggesting all these other
precautions.....
>
Most likely their concern for SQL injection attacks.
Basically any place you accept input, if you're not careful, a bad user
could do something like:
Enter First Name: dummy; select * from sysobjects
And if your select query isn't written well, it now becomes something like:
Select id from table where fname=dummy; select * from sysobjects and now
your sysobjects table has been returned to the hacker.

> Nalaka
>
> "Wei Lu" <weilu@.online.microsoft.com> wrote in message
> news:1Kfz6%23FhGHA.5608@.TK2MSFTNGXA01.phx.gbl...
character[vbcol=seagreen]
to[vbcol=seagreen]
and[vbcol=seagreen]
>|||Hi Nalaka,
Thank you for the update.
As Greg mentioned, there is some secury issue you should considered in you
application code.
SQL injection should be avoid.
You could refer the article I posted in the previous post.
SQL Injection
http://msdn2.microsoft.com/en-us/library/ms161953.aspx
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.|||Thanks...
"Wei Lu" <weilu@.online.microsoft.com> wrote in message
news:ugdnCtVhGHA.5608@.TK2MSFTNGXA01.phx.gbl...
> Hi Nalaka,
> Thank you for the update.
> As Greg mentioned, there is some secury issue you should considered in you
> application code.
> SQL injection should be avoid.
> You could refer the article I posted in the previous post.
> SQL Injection
> http://msdn2.microsoft.com/en-us/library/ms161953.aspx
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ========================================
==========
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ========================================
==========
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>|||Hi Nalaka,
Glad to hear the information is helpful.
If you have any questions or concerns, please feel free to let me know.
Sincerely,
Wei Lu
Microsoft Online Community Support
========================================
==========
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
==========
This posting is provided "AS IS" with no warranties, and confers no rights.

OSQL Unicode Insert of ^F (Hex 06) from Registry Multi-String Value is Duplicating in DB

I'm using a Unicode sql script imported using OSQL. One of the values
we are attempting to insert is a Registry Multi-String value by passing
a string to a stored procedure. These Multi-String values appear to be
delimited by a Hex 06 (^F) character. When I import this character,
embedded in a string preceeded by an N, i.e

N'something something2 something3'

I end up with TWO of this character in the db. I get :

something something2 something3

Any help figuring out why or how to fix this? We MUST use Unicode due
to extended character sets, so NOT using Unicode is NOT a solution.Seems to be an encoding issue. We are using SQLXML to retrieve the
data initially. That seems to be UTF-8 encoding the data which creates
an xml stream that contains an odd escape sequence. This escape
sequence is not then being translated into the correct unicode
representation in the insert scripts (which are created by transforming
the xml). We are going to try Unicode encoding on the SQLXmlCommand
object and setting the xml to encoding=UTF-16 to see what happens.