1

In the first step of what will build up to include several temp tables and Stored Procs being called and then Unioned, I have the first baby steps (based on the answer from Philip Kelley here):

IF OBJECT_ID ( 'RockBottomAmalgamated', 'P' ) IS NOT NULL   
    DROP PROCEDURE RockBottomAmalgamated;  
GO
CREATE PROC [dbo].[RockBottomAmalgamated]
    @BegDate datetime,
    @EndDate datetime,
    @SortBy varchar(20)
AS
CREATE TABLE #BaseCraftworksTable
 (
   Unit    varchar(25)            not null
  ,ShortName    varchar(50)
  ,ItemCode  varchar(25)  not null
  ,Description  varchar(100)  not null
  ,Price  varchar(25)
  ,Variance  varchar(25)
  ,VarianceAverage  varchar(10)
  ,PriceWeek  varchar(50)
  ,Week  varchar(10)  not null
 )

INSERT INTO #BaseCraftworksTable (Unit, ShortName, ItemCode, Description, Price,
                                  Variance, VarianceAverage, PriceWeek, Week)
 EXECUTE sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks
   @BegDate = @BegDate
  ,@EndDate = @EndDate
  ,@SortBy  = @SortBy

SELECT * FROM #BaseCraftworksTable

...but calling this SP (RockBottomAmalgamated) returns nothing; yet calling "sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks" does return records. Why would that be, as so far this is simply stuffing some of the data returned from sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks into #BaseCraftworksTable, which is then being returning its contents?

UPDATE

On trying to use the "FROM OPENROWSET()" jazz with this code:

IF OBJECT_ID ( 'RockBottomAmalgamated', 'P' ) IS NOT NULL   
    DROP PROCEDURE RockBottomAmalgamated;  
GO
CREATE PROC [dbo].[RockBottomAmalgamated]
    @BegDate datetime,
    @EndDate datetime,
    @SortBy varchar(20)
AS
CREATE TABLE #BaseCraftworksTable
 (
   Unit    varchar(25)            
  ,ShortName    varchar(50)
  ,ItemCode  varchar(25)  
  ,Description  varchar(100)  
  ,Price  varchar(25)
  ,Variance  varchar(25)
  ,VarianceAverage  varchar(10)
  ,PriceWeek  varchar(50)
  ,Week  varchar(10)  
 )

SELECT * INTO #BaseCraftworksTable FROM OPENROWSET(
   'SQLNCLI', 'Server=PLATYPUSQL42.za.ABCData;Trusted_Connection=yes;', 
   'EXEC sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks
       @BegDate = @BegDate
      ,@EndDate = @EndDate
      ,@SortBy  = @SortBy');

SELECT * FROM #BaseCraftworksTable

...I got an err msg about "BaseCraftworksTable" already existing. So I added this just before the "CREATE TABLE":

IF OBJECT_ID('#BaseCraftworksTable', 'U') IS NOT NULL
  DROP TABLE #BaseCraftworksTable; 

...but it didn't help.

So I commented out the CREATE TABLE portion; that did away with the previous error, but invoked these in its stead:

Error 53: Named Pipes Provider: Could not open a connection to SQL Server [53]. 

OLE DB provider "SQLNCLI11" for linked server "(null)" returned message "Login timeout expired".
OLE DB provider "SQLNCLI11" for linked server "(null)" returned message "A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.".

The connection value provided ("PLATYPUSQL42.za.ABCData") is exactly what I selected from the "Connection" dropdown in LINQPad (with "SQL" chosen from the Language dropdown); it works in LINQPad; what is the OPENROWSET call expecting as its second parameter?

UPDATE 2

I'm obviously not a SQL guru, but it surprised me that I could comment out my CREATE TABLE statement altogether, re-create the SP, run it, and there be no err msg about a nonexistent table. So I assume that if the table has not been defined, it is created automatically based on what's within the params in the INSERT INTO () clause. Makes sense/nice feature; but that being the case, what would be the advantage of explicitly defining the table?

NOTE: I still get no results, though; I tried that thinking maybe the problem was with how I was defining one or more of the fields in the table. But no, there's something other than that causing the problem[s]...

Community
  • 1
  • 1
B. Clay Shannon-B. Crow Raven
  • 8,547
  • 144
  • 472
  • 862
  • have you tried using `OPENROWSET()`? – S3S Jun 08 '16 at 21:18
  • Where is OPENROWSET triable? – B. Clay Shannon-B. Crow Raven Jun 08 '16 at 21:20
  • 1
    `SELECT * INTO #BaseCraftworksTable FROM OPENROWSET('SQLNCLI', 'Server=YourServer;Trusted_Connection=yes;', 'EXEC sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks (put params here)')` – S3S Jun 08 '16 at 21:23
  • 1
    They are a variety of things that could be going wrong here. In order to narrow it down some we would need to see the `sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks` proc. – RBarryYoung Jun 08 '16 at 21:27
  • 3
    As an aside, you might consider renaming your procedure. The sp_ prefix is problematic. http://sqlperformance.com/2012/10/t-sql-queries/sp_prefix – Sean Lange Jun 08 '16 at 21:30
  • 1
    Also, I would not recommend a loopback `OPENROWSET` for this, it's no more likely to work than `INSERT..EXEC`, it's kludgy, especially with having to include the parameters, and it is an opportunity to introduce other, unrelated problems (deadlocks, config settings, security issues and potential performance problems). `INSERT..EXEC` is the recommended way to do this, you just need to debug the current problem. – RBarryYoung Jun 08 '16 at 21:34
  • @RBarryYoung: Ok, I reverted back to my original approach, as it least it gave no err msgs - just no data. Do you have any recommendations on debugging it? IOW, is there a way to "step through" the process to see where exactly it's failing? Can I put "debug" statements inside the stored proc? Or...??? – B. Clay Shannon-B. Crow Raven Jun 08 '16 at 21:54
  • 1
    If you are executing it from Management Studio, just put in PRINT statements. – RBarryYoung Jun 08 '16 at 21:57
  • No, I'm using LINQPad to update the SP (drop and re-create) and a custom utility I wrote to run the SP and put its result set in a DataGridView (C# app). I have never used Management Studio, I'll see if I've got it installed. – B. Clay Shannon-B. Crow Raven Jun 08 '16 at 21:59
  • 1
    Have you tried using profiler to check what is actually being executed? It may be working, but the parameters being passed into sp_ViewPriceMatrix_RockBottomRollup_Craftworks are causing your issue. I notice that they have same names as the outer stored proc. – Duncan Howe Jun 08 '16 at 23:23
  • It is a tool that you can install as part of the client tools - SSMS. It will allow you to trace what is happening. – Duncan Howe Jun 08 '16 at 23:42
  • Take a look here:https://msdn.microsoft.com/en-us/library/ms181091.aspx It is very powerful, but don't be put off – Duncan Howe Jun 08 '16 at 23:44
  • 1
    @B.ClayShannon do you have `try-catch` block in the outer sp? Do you execute each proc with specific `schema` (e.g. `dbo.`) defined? – Ivan Starostin Jun 09 '16 at 05:20
  • @IvanStarostin: To quote the sorely-missed Scotty Briggs, "All down but nine; set 'em up on the other alley, pard." I didn't know try-catch existed in SQL, and I don't know what you mean by defining schema. – B. Clay Shannon-B. Crow Raven Jun 09 '16 at 15:25
  • 1
    In `[dbo].[something]` the "*dbo*" is the schema name. "*dbo*" is the default schema, but it is not the only one that can exist, you can create others. – RBarryYoung Jun 09 '16 at 16:40
  • @B.ClayShannon in some cases you may have default schema assigned to your login name same as you login, e.g. "ClayShannon". So when creating new object without "dbo." or other specific schema defined - it's going to be created in your default schema. Same thing with calling procs: if schema is not defined, server will first look for object with name given in your default schema, if'll fail - will look in other schemas. So there is a chance that you have different versions of same proc and in different conditions one or another is executed which may result in different output. – Ivan Starostin Jun 09 '16 at 17:53
  • 1
    I'm saying - it's possible that you have `dbo.sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks` as well as `ClayShannon.sp_ViewPriceMatrix_Variance_RockBottomRollup_Craftworks` and they are different. – Ivan Starostin Jun 09 '16 at 17:54
  • @IvanStarostin: Nope, but thanks. – B. Clay Shannon-B. Crow Raven Jun 09 '16 at 17:56

0 Answers0