Viewing 15 posts - 30,406 through 30,420 (of 59,101 total)
Create the proc on the linked server and then execute it from there.
It would also be a much better thing if someone were to properly normalize that table
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 6:29 pm
Or, you can just write a little bit of code to do the same thing. Please see the following article.
http://www.sqlservercentral.com/articles/Best+Practices/61537/
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 6:24 pm
Here's one of many solutions available as of SQL Server 2005 where the user only has EXECUTE privs on a stored procedure that uses xp_CmdShell and the user can NOT...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 6:16 pm
balbirsinghsodhi (4/9/2012)
How about doing like this ?
CREATE PROCEDURE dbo.usp_ExecCmdShellProcess
AS
BEGIN
DECLARE @job NVARCHAR(100) ;
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 6:07 pm
You might want to take a good look at the following articles before you use a recursive CTE.
http://www.sqlservercentral.com/articles/Data+Generation/87901/
http://www.sqlservercentral.com/articles/T-SQL/74118/
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:52 pm
I would NEVER give a login for a human or application the privs necessary to execute xp_CmdShell directly. In fact, I'd never give a human or application more than...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:48 pm
GilaMonster (4/9/2012)
Jeff Moden (4/9/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:34 pm
True enough. I'm really hoping that a date/time wouldn't exceed 128 characters. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:31 pm
L' Eomot Inversé (4/9/2012)
Jeff Moden (4/8/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:28 pm
opc.three (4/9/2012)
Jeff Moden (4/8/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:11 pm
opc.three (4/9/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 4:08 pm
As an alternative...
+ ' SET insert_date = ' + QUOTENAME(@InsertDate,'''')
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 7:32 am
For a bit more detail on the subject, please see the following article...
http://www.sqlservercentral.com/articles/comma+separated+list/71700/
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 7:31 am
Joining a Tally Table to VARCHAR(MAX) (during delimited splitting, for example), even if there are less than 8000 characters, will cause the join to run twice as slow as an...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 7:25 am
Although I believe that some cross-training is certainly necessary on the part of DBAs and hardcore SQL Developers, what I'd really like to see is more of those folks learning...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2012 at 7:19 am
Viewing 15 posts - 30,406 through 30,420 (of 59,101 total)