Importing SQL using a temp table

[#1]

I am having a difficult time using Stored Procedures and Temp tables in JMP 11.2.1.  I simply get no return

db = Create database Connection("DRIVER=SQL Server;

  SERVER=localserver\SQLEXPRESS;

  DATABASE=Test"

);

Execute SQL(db,

  "

  CREATE TABLE #Test ( ID int)

  Insert INTO #Test (ID)

  VALUES (1), (2), (3), (4), (5)

  SELECT *

  FROM #Test

  DROP TABLE #Test

  ",

  ":-("

);

close database connection(db);

This problem has plagued me for some time.  From the looks of it SAS can do it so I don't think it's an issue with ODBC.

[#2]

Thanks Brian, I must have just been calling it wrong. 

[#3]

It might not be your fault.  There is a bug in JMP 12 causing stored procedures not to return any rows to JMP (I'm frankly not sure how Brian got one to work).  It will be fixed in the 12.1 maintenance release, which should be out in a few months.

UPDATE:  I was confused.  The bug regarding stored procedures not returning any rows was actually *not* in JMP 12 - it was introduced and fixed within the JMP 12.1 cycle.  So you may need to look at your stored procedure code.  We have seen scenarios where a table is created and then selected from within a single stored procedure where the rows do not get returned to JMP.

Eric

[#4]

Thanks for the explanation.  However, I don't like how this works.  I should simply be able to take any query that runs fine in other applications, and see/expect the same result when ran within JMP/JSL. 

I've read though this thread and one thing is clear... the workaround discussed, splitting out all temp tables into separate queries, is NOT a good solution for us JSL Developers.  I have a large, older query that works just fine and it will literally take me hours to split it out.  What's the point of that?  How is this the preferred method?  I also noticed that in my first query split attempt, JMP isn't loading OIDs into the new Data Table.   So I'm not really sure if I can split out this query.  If I continue, I can't join on a blank OID column....  When I run this identical query portion through SQL Server, my column does have data.

I was also surprised that this topic was difficult to find -it took a few Google searches.  Limitations should be clearly stated in the JSL Manual, but this is the first I'm reading it.  I specifically wrote several helper functions -which now aren't very helpful.  Now I'm realizing it was a waste of time.  It will actually be faster for me to use another Application to write to csv, and have JMP load that.  This software is not cheap, so I'd expect Temp Tables/SQL to work in JMP instead of needing an external app to save me time.

At the very least, I'd expect this application to have better notifications.  If JMP detects temp table usage either within JSL or the "Open Table > Advanced" Platform, maybe a message should be sent to the developer to inform them that JMP cannot handle the operation...?

This thread doesn't appear active anymore... Does SAS/JMP plan on fixing this?

[#5]

The way I understood it, this isn't on the JMP side to fix.  The problem is on Microsoft's side in they way their drivers for ODBC 3.0 call it.   They could possibly try to detect #Tables as you said, but I don't think I'd want to interrupt a script to tell me that my SQL is written in an unacceptable fashion.  Passing something to the log I could see being useful though. 

[#6]

Vince,

Thanks.  Would it make sense to look for older ODBC 2.0 downloads?  I haven't had much luck yet.